Marin Fotache Dialecte DB Visual FoxPro De la simplu la complex CUVÂNT, OARECUM, ÎNAINTE Un amic, al cărui succes publicistic îl invidiez de ani buni, m-a convins că, uneori, titlul este la fel de important ca şi conţinutul unei cărţi Distinsul „cetitor” care intră în librărie sau anticariat, hotărât să nu se atingă de bruma din portmoneu, trebuie capturat cu orice preţ de o copertă viu colorată, de un titlu sprinţar şi convins să cumpere ori, în cel mai rău caz, poate pleca chinuit de păcatul de a fi lăsat cartea în raft (sentimentul se numeşte, în termeni tehnici, frustrare) Astfel, prima mea grijă a fost găsirea unui titlu straşnic SQL pentru to(n)ţi ar fi fost prea jignitor şi, oricum, nerealist Nu cred că poţi şti SQL şi să fii, simultan, tont Vă asigur că dacă vă descurcaţi cu SQL la un nivel acceptabil, sunteţi oricum, dar nu şi tont Nici Totul despre SQL nu mi s-a părut grozav în primul rând, deoarece a fost deja folosit de Corina şi Adrian Pascu Apoi, ar fi fost o exagerare Un tratat complet despre SQL s-ar întinde pe câteva mii de pagini şi, chiar şi aşa, ar mai rămâne destule puncte neatinse sau tratate superficial, motiv pentru care mi-am reprimat urgent bruma de vocaţie academistă Anxios din cale-afară, am profitat de primul vin roşu ieşit în cale şi mi-am provocat prietenii la un wine-storming Le-am povestit problema şi pe dată au început să curgă sugestiile, criticile şi propunerile Olecuţă de SQL e prea moldovenesc Polirom este o editură cu o bătaie lungă şi largă şi nu s-ar cuveni o regionalizare a ţării tocmai pe criterii SQL-istice O primă propunere serioasă a fost Esenţă de SOL Mi-a plăcut, dar parcă prea suna a elită - or, cel puţin prin titlu, cartea trebuia să se adreseze maselor largi de studenţi, informaticieni şi altora dispuşi sau siliţi să lucreze cu bazele de date încălziţi fiind, ne-am amintit de prestaţia lui Al Pacino din Parfum de femeie, aşa că următoarea idee a fost Parfum de SQL Am realizat că exagerasem, deoarece unui cârtitor versat i-ar fi trecut prin cap ideea că mai bine suna After-shave de SQL Cum apucasem să mă laud, cu câteva luni în urmă, cu rubrica din Net Report (ex-PC Report), unul dintre meseni a sugerat ca titlul cărţii să fie chiar Fiola de SQL Există deja câteva mii [zeci!, l-am corectat eu) de posibili cititori care au auzit de această expresie M-am opus net (report), din mai multe motive Nu mi s-a părut corect faţă de cei de la revistă (acum mă suspectez că am avut în vedere şi o eventuală culegere de fiole într-o altă carte, idee care, la acest moment, nu mi pare chiar realistă) Şi apoi, unde s-a mai pomenit ca o fiolă să se întindă pe câteva sute de pagini? Poate Butoiul cu SQL - dar şi asta suna ca un atac (bahic) la persoana studentului/informaticianului/ specialistului/ cumpărătorului Şi uite aşa am ajuns la prea puţin sofisticatul titlu SQL Pur şi simplu Adio regionalisme, esenţe, deodorante şi fiole Pentru a mai adăuga un pic de semnificaţie şi a ţinti câteva categorii clare de utilizatori/cumpărători ai cărţii, am mai adăugat subtitlul Dialecte DB , Oracle şi Visual FoxPro Asta e Să nu ziceţi că titlul n-are imaginaţie N-aş suporta lovitura Cartea de faţă este destinată unor grupuri de utilizatori ce folosesc sau sunt pe cale de a folosi bazele de date Pentru studenţii specializărilor Informatică Economică şi Birotică (de la Facultatea de Economie şi Administrarea Afacerilor) ar putea fi un ajutor nepreţuit în efortul supraomenesc de a promova anul de studii în care apare disciplina Baze de date (glumeam, cred că am, în rândul studenţilor, o rată de sinucideri care l-ar dezamăgi pe Cioran) Studenţii de alte facultăţi (Informatică, Cibernetică, Calculatoare) o pot folosi chiar dacă-i supără pe profesorii lor titulari întrucât am reuşit (până acum) să îmbin lucrul la catedră şi munca patriotică din facultate cu o serie de contracte/participări la realizarea unor aplicaţii (nu puţine au fost eşecurile), îndrăznesc să o recomand şi practicienilor, celor care dezvoltă aplicaţii cu baze de date, dar şi celor care au baze de date implementate de ceva timp şi vor să obţină tot soiul de informaţii şi nu au la dispoziţie un informatician sau sunt certaţi cu acesta O lucrare serioasă capătă cu adevărat prestigiu dacă prefaţa se termină cu mulţumiri întrucât aveam de acasă, ca şi laureaţii premiilor Oscar, o listă cu nume, dar am rătăcit-o pe undeva, nu-mi rămâne decât să le mulţumesc tuturor celor pe care i-am cunoscut, indiferent de media (vizual/ auditiv/e-mail/reviste), relaţii de rudenie, prietenie sau indiferenţă, precum şi celor pe care îi voi cunoaşte până la următoarea carte (când sper să le mulţumesc din nou) Unora vreau să le cer scuze dacă plăcerea lor de a mă cunoaşte nu a fost la înălţimea plăcerii mele de a-i cunoaşte Timpul nu e pierdut Ce-aţi zice să mai încercaţi o dată, cu cartea aceasta în faţă? Mă simt obligat să mărturisesc că o parte din materialul bibliografic parcurs în anii începuturilor mele în SQL (şi acum învăţ SQL, deşi nu mai am sporul de altădată) a fost preluat de pe Internet, precum şi prin fondurile Grantului finanţat de Banca Mondială şi Guvernul României Mulţumesc fondatorilor Internet-ului şi directorului grantului cu pricina - care, întâmplător, este o persoană pe care o cunosc binişor Autorul Iaşi, aprilie CONŢINUTUL LUCRĂRII Cartea începe destul de anost, cu inevitabila terorie legată de bazele de date: cum au apărut, la ce sunt folositoare, care sunt componentele unui sistem de lucru cu bazele de date, ce este un sistem de gestiune a bazelor de date (SGBD) şi care îi sunt modulele principale etc Pentru a mai atenua din durerile „teoretice”, a fost inserată şi o istorie romanţată a SGBD-urilor relaţionale Aceasta, de fapt, pentru a pregăti un nou calup teoretic, cel al noţiunilor modelului relaţional şi al restricţiilor ce pot fi definite pentru o bază de date Din păcate, aceste paragrafe chiar trebuie citite, deoarece sintagmele explicate aici sunt folosite în capitolele următoare Spre finalul primului capitol este prezentată în detaliu baza de date „martor” a lucrării, cea pe care vom opera comenzile SQL Al doilea capitol este jumătate teoretic şi restul practic Teoretic, deoarece prezintă coordonatele esenţiale ale algebrei relaţionale, limbai curat teoretic ce fundamentează SQL Sunt prezentaţi in extenso operatorii ce permit extragerea informaţiilor dintr-o bază de date, cei asamblişti - reuniunea, intersecţia, diferenţa şi produsul cartezian - şi cei relaţionali - selecţia, proiecţia, joncţiunea (de fapt joncţiunile, că sunt mai multe tipuri) şi diviziunea Aerul practic se datorează exemplelor care însoţesc fiecare operator prezentat, exemple ce utilizează baza de date descrisă în capitolul Al treilea capitol este şi cel care intră - e adevărat, nu chiar frontal - în problematica SQL Nu chiar frontal, deoarece începe, aproape inevitabil pentru o carte scrisă de un universitar, cu o scurtă istorie a limbajului Cu acest prilej sunt conturate şi direcţiile de evoluţie ale SQL După enumerarea principalelor tipuri de date gestionabile prin SQL, discuţia se concentrează asupra modalităţilor de creare a tabelelor şi mai ales de declarare (cu greu am reuşit să evit cuvântul implementare) a restricţiilor unei baze de date Formatul general din stardardul SQL- este permanent însoţit de variantele operaţionale în DB , Oracle şi Visual FoxPro, lucru ce se va repeta în capitolele ce vor urma Apropo, de ce DB , Oracle şi Visual FoxPro şi nu alte produse? în primul rând, pentru că sunt singurele dialecte SQL pe care le ştiu (cât de cât) în celelalte rânduri, pentru că: DB este produsul din care primele două standarde SQL au împrumutat cel mai mult; de altminteri, IBM este probabil firma-cheie atât în ceea ce priveşte apariţia modelului relaţional, cât şi SQL Oracle deţine, de ani buni, cea mai mare cotă din piaţa bazelor de date şi nu sunt semne vizibile că ar trece curând pe locul doi Visual FoxPro este primul SGBD „democrat” din ţara noastră - şi aceasta nu ţine atât de faptul că a apărut şi a fost utilizat după , cât mai ales de aria sa de utilizare în ţara noastră, incomparabil mai mare decât pe plan mondial Dacă, aşa cum spuneau cei din Şcoala Ardeleană, de la Rîm ne tragem, se poate spune că şi cel puţin o generaţie de dezvoltatori de aplicaţii cu baze de date din FoxPro se trage Este drept că VFP nu stă chiar pe roze, ca evoluţie mondială a numărului de dezvoltatori ce- utilizează, dar mai este, pentru multe firme mici şi mijlocii, o soluţie ce nu trebuie ridiculizată Iar pe de altă parte, n-am reuşit să rezist tentaţiei de a alătura (numai într-o carte) trei produse ale unor firme (IBM, Oracle şi Microsoft) între care relaţiile sunt cordiale o dată sau de două ori pe deceniu Una din criticile pe care mi le asum este că nu am prezentat nici un dialect din categoria SGBD-rilor gratuite, astăzi din ce în ce mai populare: PostgreSQL, MySQL, Interbase etc Poate în viitoarea ediţie a cărţii, după ce prezenta se va fi epuizat din anticariate şi de la buchinişti (vă daţi seama că lucrul acesta nu o să se petreacă prea curând, chiar dacă tirajul ar fi foarte mic) Capitolul este unul de introducere în interogările SQL, de prezentare a principalelor clauze ale frazei SELECT în parte, exemplele sunt cele din algebra relaţională, dar discuţia depăşeşte cu mult cadrul celor opt operatori din capitolul Astfel, sunt discutate: coloanele calculate (împreună cu opţiuni de concatenare şi operaţii cu date calendaristice), ordonarea liniilor în rezultatul unei interogări operatori pentru lucrul cu intervale (BETWEEN), liste (IN) şi şabloane (LIKE), sinonime locale şi autojoncţiune, funcţii de agregare (COUNT, SUM, AVG, MIN, MAX), precum şi clauzele de grupare (GROUP BY şi HAVING) Capitolul se apleacă asupra câtorva „delicatese” SQL: valori nule, joncţiune externă, structuri alternative generalizate (CASE), subconsultări (operatorul IN), operatorii ALL, SOME şi ANY şi utilizarea subconsultărilor în clauza HAVING a unei fraze SELECT Soluţiile formulate pun în evidenţă avantajele şi limitele fiecăruia dintre cele trei produse - DB , Oracle şi Visual FoxPro, în finalul capitolului sunt prezentate câteva variante de refugiu în SQL, în sensul că, atunci când dialectul produsului nu permite anumite elemente de fineţe, se poate recurge la varianta neortodoxă de a salva rezultatele consultărilor în tabele virtuale sau temporare şi folosirea acestora ca argumente în alte fraze SELECT, altfel spus, secvenţializarea interogărilor Un bonus al paragrafului îl constituie prezentarea expresiilor-tabelă din DB După cum sugerează şi titulatura, capitolul ridică frazele SELECT pe „cele mai înalte culmi ale SQL Primul paragraf este dedicat uneia dintre cele mai dificile probleme în formularea consultărilor, corelarea simplă şi, mai ales, cea dublă Prezentarea mecanismului corelărilor este însoţită de exemple ce pun în valoare utilitatea operatorului EXISTS Al doilea paragraf este mult mai puţin încordat, evocând o facilitate preferată de mulţi dintre cei ce lucrează în SQL - includerea frazelor SELECT în clauza FROM a unei consultări/subconsultări, opţiune ce furnizează soluţii pentru multe probleme informaţionale aparent insolubile , Reprezentarea structurilor ierarhice (arborescente) sunt tratate lapidar într-un paragraf special, împreună cu o serie de facilităţi Oracle în acest sens (clauzele CONNECT BY şi START WITH) Paragraful final al capitolului prezintă câteva ingrediente ale reţetei de actualizare a tabelelor prin comenzi UPDATE ce utilizează subconsultări corelate Singurul capitol care se apropie, timid, de cel mai recent standard SQL, SQL- , este cel de-al şaptelea Apropierea nu vizează, aşa cum probabil s-ar fi cuvenit, orientarea pe obiecte (în principal tipurile de date abstracte - ADT), ci un domeniu mult mai pragmatic, cel al analizei multidimensionale a datelor, domeniu consacrat în literatura de specialitate drept OLAP (On Line Analytical Processing) Nucleul OLAP din SQL- : ROLLUP, CUBE, GROUPING, GROUPING SETS, RANK, ROW NUMBER etc - este completat de câteva funcţii specifice Oracle i : PERCENT RANK, FIRST VALUE, LAST VALUE, PERCENT RANK, LAG şi LEAD ^ Ultimul capitol, al optulea, dezvoltă câteva dintre elementele prezentate în precedentele capitole, cu privire la obiecte componente ale schemei unei baze de date şi intră în câteva detalii legate de extensiile procedurale ale SQL în două dintre cele trei SGBD-uri, VFP şi Oracle In completarea opţiunilor de creare a tabelelor prin combinaţia CREATE TABLE / SELECT şi declararea restricţiilor CHECK folosind subconsultări, sunt discutate modalităţile de creare şi actualizare a tabelelor virtuale Dintre extensiile procedurale ale SQL, câteva zeci de pagini sunt cheltuite cu procedurile şi funcţiile stocate în VFP şi Oracle, precum şi un tip special de proceduri stocate - declanşatoarele Vă urez lectură plăcută şi vise frumoase Capitolul NOŢIUNI ALE MODELULUI RELAŢIONAL ’ Modelul relaţional de organizare a datelor s-a conturat în două articole publicate în şi de către E F Codd, matematician la centrul de cercetări din San Jose (California) al firmei IBM în acel moment, tehnologia bazelor de date era centrată pe modelele ierarhic şi reţea, modele ce depind într-o mai mare măsură de organizarea internă a datelor pe suportul de stocare Codd a propus o structură de date tabelară, independentă de tipul de echipamente şi software de sistem pe care este implementată, structură „înzestrată” cu o serie de operatori pentru extragerea datelor Deşi puternic matematizat, modelul relaţional este relativ uşor de înţeles Dar înainte de a intra în subiect, vom cheltui câteva pagini cu teoria referitoare la noţiunile: fişiere de date, baze şi bănci de date, sisteme de gestiune a bazelor de date Baze de date şi sisteme de gestiune a bazelor de date Conceptul de „bază de date” a apărut în a doua parte a anilor ’ La momentul respectiv, în sistemele informatice ale organizaţiilor (atâtea câte erau - vorbesc de sisteme informatice), informaţiile erau organizate în fişiere de date (secvenţiale, indexate etc ), create cu ajutorul unor programe scrise în limbaje din a IlI-a generaţie: COBOL, Fortran etc (figura ) Specific acestui mod de lucru, cunoscut ca file-based sau flat files (fişiere independente), este faptul că fiecare dată (Datai, Data , Datan) este descrisă (nume, tip, lungime), autonom, în toate fişierele în care apare Mai mult, descrierea fiecărui fişier de date (câmpurile care- alcătuiesc, tipul şi lungimea fiecăruia, modul de organizare - sercvenţial, indexat, relativ etc ) este obligatorie în toate programele care îl „citesc” sau modifică între FIŞIER/, FIŞIER , FIŞIERn nu există nici o relaţie definită explicit Spre exemplu, Data este prezentă în două fişiere de date, FIŞIER şi FIŞIER Dacă, prin program, se modifică formatul sau valoarea acesteia în FIŞIER , modificarea nu se face automat şi în FIŞIER ; prin urmare, o aceeaşi dată, Data , va prezenta două valori diferite în cele două fişiere, iar necazurile bat la uşă: informaţiile furnizate de sistemul informatic sunt redundante şi prezintă un mare risc de pierdere a coerenţei Se poate proiecta un mecanism de menţinere a integrităţii datelor, astfel încât actualizarea unei date într-un fişier să atragă automat actualizarea tuturor fişierelor de date în care apare aceasta, însă, în sistemele mari, care gestionează volume uriaşe de informaţii, implementarea unui asemenea mecanism este extrem de complexă şi costisitoare In plus, fişierele de date sunt uneori proiectate şi implementate la distanţe mari în timp, în formate diferite: de exemplu, FIŞIER este posibil să fi fost creat cu ajutorul limbajului COBOL, FIŞ ER în FORTRAN, iar FIŞIER în BASIC în asemenea condiţii, punerea în operă a mecanismului de menţinere a integrităţii devine o utopie  Chiar numai şi din cele prezentate mai sus, se pot desprinde câteva dezavantaje ale organizării datelor după modelul file-based : » Redundanţa şi inconsistenţa datelor: o aceeaşi dată apare în mai multe fişiere; în aceste cazuri există riscul modificării acesteia într-un fişier fară a face modificările şi în toate celelalte fişiere Dificultatea accesului într-o întreprindere, o aceeaşi informaţie este exploatată de mai mulţi utilizatori Spre exemplu, pentru departamentul care se ocupă cu gestiunea stocurilor, intrările de materiale trebuie ordonate pe magazii (depozite) şi repere, în timp ce pentru departamentul care se ocupă cu decontările cu partenerii de afaceri ai întreprinderii, intrările trebuie ordonate pe furnizori ai materialelor Or, fişierele tradiţionale nu facilitează accesarea datelor după mai multe criterii, specifice diferiţilor utilizatori sau grupuri de utilizatori Izolarea datelor: când datele sunt stocate în formate diferite, este dificil de scris programe care să realizeze accesarea datelor într-o manieră globală a tuturor celor implicate în derularea unei tranzacţii Complexitatea deosebită a actualizărilor O actualizare presupune adăugarea, modificarea sau ştergerea unor informaţii din fişiere Cum prelucrările se desfăşoară în timp real, de la mai multe terminale (în mediile multi-utilizator), pot apărea situaţii conflictuale atunci când doi utilizatori doresc modificarea simultană a unei aceleaşi date Rezolvarea acestui gen de conflicte presupune existenţa unui program-supervizor al prelucrărilor, care este greu de realizat cu o multitudine de fişiere, create la distanţă în timp şi în formate diferite Problemele de securitate ţin de dificultatea creării unui mecanism care să protejeze pe deplin datele din fişiere de accesul neautorizat Probleme legate de integritatea datelor Informaţiile stocate în fişiere sunt supuse la numeroase restricţii semantice Toate aceste restricţii alcătuiesc mecanismul de integritate a datelor, deosebit de complex în mediile de lucru multi-utilizator şi eterogene Inabilitatea de a obţine răspunsuri rapide la probleme ad-hoc simple Costul ridicat se datorează gradului mare de redundanţă a datelor, eforturilor deosebite ce trebuie depuse pentru interconectarea diferitelor tipuri de fişiere de date şi pentru asigurarea funcţionării sistemului în condiţiile respectării unui nivel minim de integritate şi securitate a informaţiilor ® Inflexibilitatea faţă de schimbările ulterioare, ce sunt inerente oricărui sistem informaţional Modelarea inadecvată a lumii reale • Sintagma bază de date apare pentru prima dată în titlul unei conferinţe organizate la Santa Monica (California) în de System Development Corporation Majoritatea lucrărilor consideră ca moment al consacrării termenului anul , când CODASYL publică, în cadrul unei conferinţe dedicate limbajelor de gestiune a datelor, primul raport tehnic [CODASYL ] în care este prezentat conceptul de „bază de date” Faţă de modelul flle- -based, noutatea o constituie existenţa unui fişier de descriere globală a bazei, astfel încât să se poată asigura independenţa programelor faţă de date, după cum o arată şi figura BAZA DE DATE  Avantajele organizării informaţiilor în baze de date decurg tocmai din existenţa acestui fişier de descriere globală a bazei, denumit, în general, dicţionar de date (denumit şi repertoar de date sau catalog de sistem) Extragerea şi modificarea datelor - altfel spus, lucrul cu fişierele de date - se derulează exclusiv prin intermediul dicţionarului în care se găsesc informaţii privitoare la structura datelor şi restricţiile îndeplinite de acestea Iată câteva dintre avantaje: Un grad redus de redundanţă a datelor Evitarea, în mai mare măsură, a inconsistenţei datelor Facilitarea partajării informaţiilor între toţi utilizatorii acestora din cadrul organizaţiei Suport pentru standardizare Implementarea unor mecanisme ameliorate privind asigurarea securităţii informaţiilor îmbunătăţirea integrităţii datelor Un mai bun suport pentru rezolvarea conflictelor ce apar la încercările de modificare simultană a unei aceleiaşi date (de către doi sau mai mulţi utilizatori) » Structurile de date sunt mai aproape de realitate şi mai uşor de manipulat Este permisă legătura cu diverse limbaje-gazdă întreprinderea poate fi abordată global, luându-se în considerare şi interacţiunile dintre compartimente (producţie, marketing, personal, finanţe, contabilitate) Datele fiind separate de programele de consultare şi actualizare a lor, procesul de dezvoltare a aplicaţiilor-program este sensibil ameliorat, efortul de scriere a programelor (codarea) diminuându-se considerabil Sistemele informatice ce utilizează baze de date sunt mai flexibile, reflectă mai bine specificul firmei, fiind adaptabile la modificările ulterioare ale mediului economic O bază de date (BD) reprezintă un ansamblu structurat de fişiere care grupează datele prelucrate în aplicaţiile informatice ale unei persoane, grup de persoane, întreprinderi, instituţii etc Formal, BD poate fi definită ca o colecţie de date aflate în interdependenţă, împreună cu descrierea datelor şi a relaţiilor dintre ele, iar după G D Everest, o BD reprezintă o colecţie de date utilizată într-o organizaţie, colecţie care este automatizată, partajată, definită riguros (formalizată) şi controlată la nivel central Bazele de date evoluează în timp, în funcţie de volumul şi complexitatea proceselor, fenomenelor şi operaţiunilor pe care le reflectă Ansamblul informaţiilor stocate în bază la un moment dat constituie conţinutul sau instanţierea sau realizarea acesteia Organizarea bazei de date se reflectă în schema sau structura sa, ce reprezintă un ansamblu de instrumente pentru descrierea datelor, a relaţiilor dintre acestea, a semanticii lor şi a restricţiilor !a care sunt supuse în timp ce volumul prezintă o evoluţie spectaculoasă în timp, schema unei baze rămâne relativ constantă pe tot parcursul utilizării acesteia Niveluri de abstractizare a datelor într-un sistem informatic ce utilizează BD, organizarea datelor poate fi analizată din mai multe puncte de vedere şi pe diferite paliere De obicei, abordarea se face pe trei niveluri fizic sau intern, conceptual sau global şi extern Nivelul Fizic (sau intern) Reprezintă modalitatea efectivă în care datele sunt „scrise” pe suportul de stocare - disc magnetic, disc optic, bandă magnetică etc Structura datelor este descrisă foarte detaliat, fiind accesibilă numai specialiştilor (ingineri de sistem, programatori în limbaje de asamblare sau alte limbaje apropiate de „maşină”) Cele două părţi principale ale bazei la acest nivel sunt: ( ) un set de programe care interacţionează cu sistemul de operare pentru îmbunătăţirea managementului bazei de date şi ( ) fişierele stocate în memoria externă a calculatorului Fişierele ce conţin datele propriu-zise sunt alcătuite din articole sau înregistrări cu format comun La acest nivel, structura BD se concretizează în schema internă Nivelul conceptual (sau global) Este nivelul imediat superior celui fizic, datele fiind privite prin prisma semanticii lor; interesează conţinutul lor efectiv, precum şi relaţiile care le leagă de alte date Reprezintă primul nivel de abstractizare a lumii reale observate Obiectivul acestui nivel îl constituie modelarea realităţii considerate, asigurându-se independenţa bazei faţă de orice restricţie tehnologică sau echipament anume întreaga bază este descrisă prin intermediul unui număr restrâns de structuri Toţi utilizatorii îşi exprimă nevoile de date la nivel conceptual, prezentându-le administratorului bazei de date, acesta fiind cel care are o viziune globală necesară satisfacerii tuturor cerinţelor informaţionale La acest nivel, structura BD se concretizează în schema conceptuală Nivelul extern Este ultimul nivel de abstractizare la care poate fi descrisă o bază de date Structurile de la nivelul conceptual sunt relativ simple, însă volumul lor poate fi deconcertant Iar dacă la nivel conceptual baza de date este abordată în ansamblul ei, în practică, un utilizator sau un grup de utilizatori lucrează numai cu o porţiune specifică a bazei, în funcţie de departamentul în care îşi desfăşoară activitatea şi de atribuţii Simplificarea interacţiunii utilizatori-bază, precum şi creşterea securităţii bazei sunt deziderate ale unui nivel superior de abstractizare, care este nivelul extern Astfel, structura BD se prezintă sub diferite machete, cunoscute uneori şi ca sub-scheme, scheme externe sau imagini, în funcţie de nevoile fiecărui utilizator sau grup de utilizatori Luând în considerare cele trei niveluri de abstractizare, schematizarea unui sistem de lucru cu o bază de date se poate face ca în figura  Accesul utilizatorului la informaţiile din bază este posibil numai prin intermediul sistemului de gestiune a bazei de date în general, interfaţa utilizator-SGBD se poate realiza în două moduri: Printr-un mecanism de apel (cuvânt-cheie, ca de exemplu CALL) inserat în programele scrise într-un limbaj „tradiţional” (C, COBOL etc ), acesta fiind cazul SGBD-urilor cu limbaj-gazdâ Prin comenzi speciale utilizate autonom (în afara aplicaţiilor-program), în cazul SGBD-urilor autonome Utilizator Al Utilizator A Interfaţă dintre nivelurile fizic şi global Definirea structurii interne de stocare (Schema internă) Figura Schematizarea unui sistem de lucru cu o bază de date Posibilitatea modificării structurii la un nivel, fară a afecta structura nivelului sau nivelurilor superioare, se numeşte autonomie a datelor stocate în bază Se poate vorbi de două paliere de autonomie Autonomia fizică reprezintă posibilitatea modificării arhitecturii bazei la nivel intern, fară ca aceasta să necesite schimbarea schemei conceptuale şi rescrierea programelor pentru exploatarea bazei de date Asemenea modificări sunt necesare uneori pentru ameliorarea performanţelor de lucru (viteză de acces, mărimea fişierelor etc ) Tot autonomia fizică este cea care asigură portarea bazei de date de pe un sistem de calcul pe altul fară modificarea schemei conceptuale şi a programelor Autonomia logică presupune posibilitatea modificării schemei conceptuale a bazei (modificare datorată necesităţii rezolvării unor noi cerinţe informaţionale) fără a rescrie programele de exploatare Autonomia logică a datelor este mai greu de^ realizat decât autonomia fizică, deoarece programele de exploatare sunt dependente, în foarte mare măsură, de structura logică a datelor pe care le consultă şi actualizează, în ciuda existenţei dicţionarului de date Fireşte, un element important îl reprezintă şi anvergura modificării schemei conceptuale Sisteme de gestiune a bazelor de date Apărute în anii ’ , Sistemele de Gestiune a Bazelor de Date (prescurtat SGBD-uri) reprezintă un ansamblu de programe ce permit utilizatorilor să interacţioneze cu o bază de date, în vederea creării, actualizării şi interogării acesteia SGBD-ul este cel care asigură şi supervizează: introducerea de informaţii în baza de date; actualizarea şi extragerea datelor din bază; autorizarea şi controlul accesului la date; păstrarea independenţei dintre structura bazei şi programe Obiectivul esenţial al unui SGBD este furnizarea unui mediu eficient, adaptat utilizatorilor care doresc să consulte sau să actualizeze informaţiile conţinute în bază Bazele de date sunt concepute pentru a prelucra un volum mare de informaţii Gestiunea acestora impune nu numai o structurare riguroasă a datelor, dar şi o raţionalizare a procedurilor de acces şi prelucrare Principalele funcţiuni ale unui SGBD vizează: descrierea ansamblului de date la nivelurile fizic şi conceptual; crearea (iniţializarea) şi exploatarea (consultarea şi actualizarea) bazei de date; » controlul integrităţii bazei; confidenţialitatea informaţiilor conţinute în bază; accesul simultan al mai multor utilizatori la informaţii; ® securitatea în funcţionare; furnizarea unui set de comenzi şi instrucţiuni necesare atât utilizatorilor pentru consultarea directă a bazei, prin intermediul unui limbaj de manipulare, cât şi programatorilor, pentru redactarea programelor de lucru cu baza de date; revizia şi restructurarea bazei; ® monitorizarea performanţelor Un SGBD prezintă, în general, următoarele module: © Gestionarul fişierelor, care se ocupă cu afectarea spaţiilor de memorie pe disc şi cu structurile fizice de date care servesc la reprezentarea informaţiilor pe suport © Gestionarul bazei de date face legătura datelor „fizice” din bază cu aplicaţiile-program de consultare şi actualizare © Procesorul de consultare „traduce” instrucţiunile limbajului de consultare în instrucţiuni elementare, „inteligibile” pentru gestionarul bazei Mai mult, acesta optimizează consultarea, pentru a obţine rezultatele într-un timp cât mai scurt © Modulele DML (Data Manipulation Language) realizează conversia instrucţiunilor limbajului de manipulare a datelor (DML) inserate într-un program de aplicaţie în proceduri curente ale limbajului-gazdă, interacţionând cu procesorul de consultare în vederea producerii secvenţelor de cod adecvate © Modulele Limbajului de Definire a Datelor — DDL (Data Definition Language) „traduc” (prin compilare sau interpretare) şi execută instrucţiunile DDL, obţinându-se ansamblul de tabele ce reprezintă metadatele stocate în dicţionarul de date Aceste cinci module interacţionează cu o serie de componente fizice ale bazei Fişierele de date reprezintă suportul propriu-zis al bazei „ Dicţionarul de date înmagazinează informaţii relative la structura bazei, fiind solicitat în toate operaţiunile de consultare şi actualizare Indecşi, într-un număr suficient pentru mărirea vitezei de acces la date Sintetic, structura unui sistem de lucru cu o bază de date este prezentată în figura Coduri-obiect ale aplicaţiilor-program Sistemul de gestiune a bazei de date  [Fişier de date J Dicţionar de date   = { / / }) Tabela LINIIFACT (figura ) detaliază tabela precedentă Un tuplu se referă la un produs/serviciu vândut şi consemnat într-o factură emisă Pentru fiecare factură vor fi atâtea linii câte produse/servicii au fost consemnate la vânzarea respectivă Atribute: NrFact-numărul facturii; Linie - numărul liniei din factura respectivă; CodPr - codul produsului/serviciului vândut; Cantitate - cantitatea vândută; PretUnit - preţul unitar (fară TVA) la care s-a făcut vânzarea  Cheia primară este combinaţia NrFact+Linie NrFact şi CodPr sunt chei străine Pentru a determina valoarea de încasat a unei facturi (inclusiv TVA), la valoarea fară TVA pentru fiecare linie (obţinută prin produsul Cantitate  PretUnit) trebuie adăugată TVA colectată, obţinută prin aplicarea procentului de TVA al produsului/serviciului (atributul ProcTVA din PRODUSE) la valoarea fară TVA Tabela ÎNCASĂRI (figura ) reprezintă un nomenclator al încasărilor Printr-o încasare, un client îşi stinge una sau mai multe obligaţii de plată, adică achită una sau mai multe facturi Documentul primar pe baza căruia se consemnează încasarea poate fi ordinul de plată, cecul, chitanţa etc Atributele tabelei sunt: L NIIFACT NrFact Linie CodPr Cantitate PretUnit                                                                                                                                      Figura Tabela LINIIFACT data documentului de încasare nu poate fi anterioară datei de început a aplicaţiei: august (DataDoc >= - - ); codul documentului se scrie numai cu majuscule INCASARI Codlnc Datalnc CodDoc NrDoc DataDoc    / / OP   / /    / / CHIT   / /    / / OP   / /   /  / / CEC   / /    / / OP   / /    / / OP   / /  Figura Tabela ÎNCASĂRI Tabela INCASFACT (figura ) detaliază tabela precedentă şi indică ce facturi (tranşe din facturi) sunt achitate prin fiecare încasare Un client poate plăti mai multe facturi odată (printr-o singură plată) Pe de altă parte, orice factură poate fi plătită în una sau mai multe tranşe, în funcţie de banii de care dispune clientul la momentul întocmirii documentului de plată Atributele tabelei sunt: Codlnc - codul încasării; NrFact - factura pentru care se încasează valoarea integrală sau numai o tranşă; Transa - tranşa din factură (sau întreaga valoare) care se încasează prin documentul primar ce stă la baza încasării INCASFACT Codlnc NrFact Transa                                      Figura Tabela INCASFACT Cheia primară este combinaţia Codlnc+NrFact, deoarece la o încasare se pot achita mai multe facturi, iar pe de altă parte, o factură poate fi plătită în mai multe tranşe Codlnc şi NrFact sunt chei străine Comentarii suplimentare privind restricţiile referenţiale Instituirea unei restricţii referenţiale într-o bază de date interzice apariţia de valori nenule în tabele-copil care nu se regăsesc în tabelele-părinte (linii orfane) De aceea, la inserarea unei linii într-o tabelă-copil sau modificarea unei chei străine, SGBD-ul trebuie să verifice dacă noile valorile se regăsesc în linii-părinte înserarea unei linii într-o tabelă-părinte, ca şi ştergerea de linii dintr-o tabelă-copil nu prezintă nici un pericol „referenţial” La ştergerea unei linii dintr-o tabelă-părinte trebuie precizat cum se va prezerva restricţia referenţială: fie prin ştergerea în cascadă a tuturor înregistrărilor-copil (ON DELETE CASCADE), fie, pur şi simplu, prin interzicerea ştergerii (ON DELETE RESTRICT) In fine, la modificarea unei chei primare/alternative pentru care există, în alte tabele, înregistrări-copil trebuie precizată acţiunea întreprinsă de SGBD: modificarea în cascadă a tuturor liniilor-copil (ON UPDATE CASCADE) sau interzicerea modificării, dacă există cel puţin o înregistrare-copil (ON UPDATE RESTRICT) Pentru exemplificare, să luăm cazul tabelei FACTURI şi trei situaţii legate de actualizarea acesteia » Inserarea unei linii Deoarece FACTURI este legată (ca tabelă-copil) prin restricţie referenţială de tabela CLIENŢI (părinte), trebuie verificat dacă valoarea CodCl există în CLIENŢI Dacă nu, inserarea trebuie prohibită ® Modificarea unei linii Aici sunt două situaţii, corespunzătoare posturilor de părinte şi copil a tabelei modificate Astfel: dacă se modifică valoarea atributului CodCl, trebuie verificat dacă aceasta se regăseşte în CLIENŢI şi, dacă nu, operaţiunea trebuie anulată; dacă se modifică valoarea lui NrFact, atunci trebuie testat dacă există înregistrări- -copil în tabelele LINIIFACT şi INCASFACT Dacă da, fie se interzice modificarea (ON UPDATE RESTRICT), fie se modifică în cascadă toate liniile-copil - valorile NrFact din LINIIFACT şi INCASFACT (ON UPDATE CASCADE) Fireşte, nu e obligatoriu ca acţiunea să fie identică pentru ambele tabele-copil Cu alte cuvinte, se poate recurge, pentru LINIIFACT, la ON UPDATE CASCADE, iar pentru INCASFACT, la ON UPDATE RESTRICT o Ştergerea unei linii Atunci trebuie testat dacă există înregistrări-copil în tabelele LINIIFACT şi INCASFACT Dacă da, fie se interzice ştergerea (ON DELETE RESTRICT), fie se şterg în cascadă toate liniile-copil din LINIIFACT şi INCASFACT (ON DELETE CASCADE) Există diferenţe semnificative între SGBD-uri în privinţa definirii acţiunilor ce trebuie întreprinse pentru respectarea integrităţilor referenţiale Unele produse - fireşte, dintre cele mai bine cotate - permit, la declararea restricţiilor referenţiale (este de obicei simultană cu crearea tabelelor), instituirea oricărei reguli din cele patru: ON UPDATE CASCADE, ON UPDATE RESTRICT, ON DELETE CASCADE, ON DELETE RESTRICT Altele, precum Oracle , permit declararea acţiunilor numai pentru ştergere, ON DELETE CASCADE şi ON DELETE RESTRICT Pentru modificarea în cascadă sunt necesare declanşatoare speciale construite în limbajul de dezvoltare - PL/SQL Cât priveşte Visual FoxPro , al treilea SGBD pe care îl vom folosi în exemplele din capitolele următoare, este interesant faptul că toate acţiunile pot fi definite, dar numai grafic, prin Referenţial Integrity Builder în schimb, dezvoltatorii de aplicaţii trebuie să scrie şi să implementeze declanşatoare în care să se descrie explicit ce trebuie întreprins în fiecare situaţie ce pune în pericol restricţiile referenţiale Alte noţiuni ale SGBD-urilor relaţionale Este greu de inventariat toate sintagmele vehiculate de dezvoltatorii de aplicaţii cu baze de date, cu atât mai mult cu cât unele sunt specifice fiecărui produs în cele ce urmează ne vom opri, pentru câteva minute, la tabelele derivate (view-urile) şi procedurile stocate Tabele virtuale (view-uri) O altă noţiune (alunecoasă) a modelului relaţional este cea căreia, prin traducerea din „originalul” view (imagine, vedere), i s-au asociat multiple titulaturi în literatura de specialitate şi practica din ţara noastră: imagine, relaţie (tabelă) virtuală, relaţie (tabelă) derivată sau relaţie (tabelă) dinamică O relaţie virtuală stabileşte o legătură semantică între relaţii statice şi/sau alte relaţii dinamice, nefiind definită explicit, prin tupluri proprii, ca o relaţie de bază (statică), ci printr-o expresie relaţională Conţinutul (instanţierea) relaţiei virtuale depinde, la un moment oarecare dat, de conţinutul tabelelor de bază din care derivă Pentru a înţelege mai bine diferenţa, explicaţia se poate rezuma astfel: tabela virtuală este cea pentru care pe disc se memorează numai schema, nu şi conţinutul Tabelele virtuale oferă oricărui utilizator al unei baze de date posibilitatea prezentării datelor în funcţie de nevoile sale specifice De asemenea, raţiuni de securitate şi confidenţialitate a anumitor informaţii pot conduce la izolarea unor date faţă de utilizatorii neautorizaţi, lucru deplin posibil prin intermediul imaginilor Pornind de la aceleaşi tabele de bază, se pot crea un mare număr de tabele virtuale, în funcţie de situaţie Tabelele derivate sunt suportul creării schemelor externe O dată definită, o tabelă virtuală poate fi privită ca o tabelă de bază oarecare De asemenea, ca şi relaţiile de bază, şi „imaginile” pot fi actualizate, ceea ce atrage modificarea tabelelor statice din care derivă In aceste situaţii apar o serie de probleme Este clar că modificarea conţinutului tabelelor de bază presupune modificarea conţinutului tabelei (sau tabelelor) derivate Insă ce informaţii pot fi modificate în tabelele de bază, pornind de la modificările tabelei virtuale? Soluţiile implementate în SGBDR-urile actuale diferă de la caz la caz Pentru a intra în câteva detalii, să imaginăm o tabelă derivată denumită ÎNCASĂRI CLIENŢI - figura -, ce conţine documentul de încasare, suma încasată (corespunzătoare documentului) şi clientul care a efectuat plata INCASARI CLIENŢI Client CodDoc NrDoc DataDoc SumaPlata  Client SRL CEC   -Auc|-   Client SRL OP   -Auq-   Client SRL OP   -Aug-   Client SRL OP   -Aug-   Client SA OP   -Auq-   Client SRL CHIT   -Aug-   Figura O tabelă derivată Utilitatea unei asemenea relaţii virtuale poate fi certificată de un angajat al compartimentului financiar care se ocupă, printre altele, şi cu evidenţa încasărilor de la clienţi Pe cât de utilă, pe atât de problematică devine ÎNCASĂRICLIENŢI atunci când se pune problema actualizării sale şi propagării modificărilor în tabelele de bază din care provine, CLIENŢI, FACTURI, ÎNCASĂRI şi INCASFACT ze Iată câteva dintre probleme: ne modificarea atributului Suma Plata este imposibil de operat în tabela de bază, INCASFACT O linie din tabela derivată corespunde uneia sau mai multor linii din tabela de bază (în funcţie de câte facturi sunt achitate prin documentul de plată respectiv) Dacă pentru ordinul de plată din august se doreşte modificarea (corecţia) sumei din în , nu se poate cunoaşte tranşa şi factura unde in s-a comis eroarea şi, normal, unde trebuie operată modificarea ie • modificarea celui de-al cincilea tuplu din (Client SA, OP, , -Aug- , ă) ) în (Client SRL, OP, , -Aug- , ), adică modificarea clientului pentru Ordinul de plată poate fi operată în trei moduri în tabele de bază: ţii - fie se modifică în FACTURI pentru factura valoarea atributului CodCl din ci în ; in - fie se modifică în linia din INCASFACT codul încasării din în ; ai - fie se modifică în INCASFACT valoarea atributului NrFact din în , sc păstrând neschimbat codul încasării Chiar dacă nu la fel de plauzibile, cele trei variante generează o „stare” de confuzie j pentru SGBD -ii • inserarea unei linii în tabela derivată este o acţiune temerară, dar fără prea mulţi sorţi de le izbândă: oricare ar fi cele trei tabele de bază unde are loc inserarea, cel puţin un atribut important (ce nu poate avea valori NULL) nu are valori specificate, astfel încât se încalcă una dintre restricţii (de entitate sau comportament) Spre exemplu, convenim că inserarea trebuie să se propage numai în INCASFACT Nu se cunoaşte însă numărul facturii încasate Cum NrFact este un component al cheii primare a tabelei, este clar j că operaţiunea va fi interzisă de SGBD • ştergerea unei linii din tabela derivată ridică problema identificării liniei sau liniilor din , una sau mai multe tabele de bază le Păstrarea integrităţii BD în momentul actualizării unei tabele derivate se poate rezolva, tă în principiu, prin „apelarea” la una dintre următoarele trei soluţii : •a • Actualizarea unei relaţii dinamice se face exclusiv pornind de la tabelele de bază din care derivă Este cea mai restrictivă şi în contradicţie cu regulile ce definesc un SGBDR, aşa cum au fost ele definite de Codd Definirea unor proceduri generale de corespondenţă, pomindu-se de la expresia relaţională de creare a tabelei derivate, proceduri pe baza cărora SGBD-ul va „traduce” actualizarea tabelei virtuale în modificări ale tabelelor de bază Controlul actualizării relaţiei derivate prin intermediul unui sub-sistem de integritate al bazei de date Această soluţie este considerată ca fiind cea mai eficace pentru păstrarea coerenţei şi securităţii întregului ansamblu de relaţii ce alcătuiesc baza de date, fie ele statice sau dinamice Pe de altă parte, nu toate tabelele derivate sunt atât de problematice precum cea discutată anterior, astfel încât propagarea modificărilor dintr-o relaţie virtuală poate fi destul de simplă După cum vom vedea în capitolele viitoare, restricţiile la care trebuie să se supună o tabelă derivată petru a putea fi modificabilă diferă de la un SGBD la altul Câteva dintre SGBDR-urile actuale propun un alt mecanism oarecum apropiat de cel al tabelei virtuale, anume cel de clişeu sau imagine concretă Acestă noţiune este fondată pe conţinutul unei „imagini” calculate pe baza definiţiei sale şi stocată în baza de date O „imagine concretă” reflectă starea bazei de date la un moment t când a fost „calculată”, clişeul fiind deci determinat periodic de către sistem Actualizarea bazei de date va fi reflectată în clişeu abia în momentul primului calcul de după aceasta Fireşte, la un volum mare al bazei de date, timpul de calcul poate fi destul de lung De aceea, se poate institui un mecanism de schimbare în clişeu numai a tuplurilor ce au suferit modificări după calculul precedent Probleme mai delicate apar la ştergerea unor tupluri în tabelele de bază, deoarece un tuplu din clişeu poate proveni din mai multe relaţii, iar ştergerea unuia într-o astfel de relaţie nu trebuie să atragă neapărat ştergerea din clişeu Proceduri stocate O procedură stocată este o secvenţă de program (cod) care face parte integrantă din baza de date Avantajele utilizării procedurilor stocate decurg din faptul că acestea sunt parte din structura (schema) bazei, fiind păstrate în dicţionarul de date (catalogul sistem) Există mai multe tipuri de proceduri stocate: funcţii-utilizator pentru validarea tabelelor, funcţii pentru calculul unor valori implicite, proceduri/funcţii de validare la nivel de linie sau tabelă, funcţii/proceduri de calcul a unor expresii complexe etc Declanşatorul (trigger) este un tip special de procedură stocată care este executată automat când un eveniment predefinit (inserare, actualizare sau ştergere) modifică o tabelă Utilitatea declanşatoarelor este evidentă la formularea unor restricţii mai complexe decât „suportă” comenzile CREATE /ALTER TABLE, actualizarea automată a unor atribute calculate, jumalizarea modificărilor suferite de baza de date, păstrarea integrităţii referenţiale etc Există diferenţe sensibile între SGBD-uri şi în ceea ce priveşte sintaxa declanşatoarelor, deoarece acestea sunt redactate în extensiile procedurale ale SQL care prezintă diferenţieri majore de la un producător la altul Poate fi evocată, spre exemplu, diversitatea declanşatoarelor în Oracle, DB etc faţă de Visual FoxPro Astfel, dacă în VFP există numai trei tipuri de declanşatoare, pentru adăugare, pentru modificare şi pentru ştergere, în schimb, în Oracle, pentru fiecare din cele trei operaţiuni există o primă separare între declanşatoare lansate înaintea operaţiei (actualizării) şi cele după operaţie La această delimitare se mai adaugă şi cea dintre triggere la nivel de linie, ce intră în acţiune la fiecare inserare/modificare/ştergere a unei linii, şi cele la nivel de comandă, care se execută o singură dată, indiferent câte linii afectează comanda de actualizare respectivă (row versus statement) Detalii despre declanşatoare în Visual FoxPro şi Oracle vor fi prezentate în capitolul Regulile modelului relaţional în , Codd a publicat în revista Computerworld un articol în care formulează reguli, plus regula , de fundament, care ar trebui respectate de un SGBD pentru a fi declarat relaţional Mai mult, autorul s-a angajat cu înverşunare împotriva celor care au folosit abuziv sintagma relaţional pentru produsele lor, chiar două firme fiind aduse în pragul falimentului de atacurile „demascatoare” ale lui Codd, sau cel puţin aşa spune legenda Discutabile, ca orice reguli, „cele porunci” constituie un etalon plauzibil de a caracteriza funcţionalităţile unui SGBD şi a- încadra pe scala relaţională Regula de fundament Orice sistem declarat relaţional trebuie să fie capabil să administreze întreaga bază de date exclusiv prin funcţiuni relaţionale Regula informaţiei Toate informaţiile sunt reprezentate explicit, la nivel logic, într-un singur mod, ca valori în anumite tabele Regula accesului garantat Orice dată elementară (reprezentată printr-o valoare atomică) este accesibilă, fară ambiguitate, prin cunoaşterea numelui tabelei din care face parte, a denumirii atributului care o reprezintă şi a valorii cheii primare a tuplului pe care se găseşte Prelucrarea sistematică a valorilor nule Un SGBDR utilizează valorile nule (diferite de valorile vide, spaţii sau ) în vederea reprezentării informaţiilor care lipsesc, necunoscute sau inaplicabile Poate avea valori NULLe orice tip de atribut Regula catalogului actualizabil în timp real Descrierea unei BDR este stocată, la nivel logic, într-un catalog (dicţionar de date) alcătuit din tabele-sistem ce pot fi consultate de o manieră similară tabelelor de date obişnuite Regula sub-limbajului de date se referă la existenţa cel puţin a unui limbaj (ca SQL, de exemplu) „dotat” cu o serie de comenzi cu sintaxă bine definită, prin care să se realizeze: definirea (descrierea) datelor; ® definirea sub-schemelor („machete” sau tabele virtuale); manipularea datelor (interactiv sau prin program); ® definirea şi implementarea restricţiilor de integritate; ® autorizarea accesului la date; ® gestiunea tranzacţiilor Limbajul trebuie să prezinte o sintaxă liniară şi să poată fi utilizat atât interactiv, cât şi din cadrul aplicaţiilor Regula actualizării tabelelor virtuale Orice tabelă derivată teoretic actualizabilă trebuie să aibă acelaşi regim în cadrul SGBD-ului Inserarea, modificarea şi ştergerea pot fi efectuate prin intermediul unui limbaj de nivel înalt, orientat pe lucrul simultan cu un ansamblu de linii Ca efect, o tabelă de bază sau derivată poate fi operand nu numai în interogări, dar şi în operaţiuni de inserare/ modificare/ştergere Independenţa fizică a datelor Aplicaţiile-program şi activităţile de tip „consolă” (interogări directe) rămân neschimbate, din punct de vedere logic, la modificarea în structurile de stocare şi metodele de acces Independenţa logică a datelor Această regulă permite modificarea dinamică a modelului logic al bazei de date, cum ar fi, spre exemplu, o descompunere (spargere) sau joncţionare de tabele care nu atrage pierderi de informaţii Independenţa mecanismului de integritate al bazei Restricţiile de integritate sunt definite printr-un limbaj relaţional şi stocate în dicţionarul de date (catalog), şi nu în aplicaţiile ce exploatează BD Dintre aceste restricţii trebuie să fie implementabile măcar două, cea a entităţii şi cea referenţială Regula independenţei distribuirii datelor Limbajul relaţional operează asupra datelor care sunt plasate atât pe calculatorul pe care se derulează activităţile, dar şi pe alte calculatoare legate în reţea, de o manieră transparentă pentru utilizator Regula non-subversiunii Dacă un sistem relaţional prezintă un limbaj de nivel scăzut (apropiat de „maşină”), care permite prelucrarea, pe rând, a fiecărei înregistrări (linii sau tuplu), acest limbaj nu poate fi utilizat pentru a încălca restricţiile declarate printr-un alt limbaj, de nivel înalt, al SGBD Cum găsirea unor SGBD-uri care să îndeplinească toate „poruncile” se dovedeşte o muncă aproape zadarnică (nu cunosc nici un SGBD în totală conformitate cu toate cele reguli), s-a încercat formularea unor cerinţe minimale pentru care un sistem de gestiune a bazelor de date să fie declarat „relaţional” Acestea ar fi: © Toate datele bazei sunt organizate în relaţii © între tabele nu există pointeri care să fie gestionaţi de utilizatori © Sunt implementaţi operatorii relaţionali: selecţie, proiecţie şi joncţiune naturală Un sistem este complet relaţional dacă, în plus: © Sunt implementaţi toţi operatorii algebrici relaţionali © Sunt respectate restricţiile de unicitate a cheii şi cea referenţială Sistemele care îndeplinesc numai condiţiile © şi © sunt pseudorelaţionale, iar dintre cele pseudorelaţionale, cele care îndeplinesc © numai în raport cu funcţia de interogare sunt denumite SGBD-uri cu interfaţă relaţională în afara celor porunci, Codd a mai specificat reguli structurale, reguli de intregritate şi reguli de manipulare Ulterior, a transformat poruncile în veritabilă Constituţie, formulând, în a doua versiune a modelului relaţional, de reguli Dacă se mai străduieşte un pic şi mai extrage încă un rând de specificaţii, obţinem de reguli, iar atunci se poate spune că modelul relaţional este unul dumnezeiesc Capitolul ALGEBRA RELAŢIONALĂ în primul capitol am văzut că modelul relaţional formulat de Codd are la bază trei elemente: structuri, operaţii şi reguli de integritate Pentru exprimarea operaţiilor aplicabile structurilor de date, autorul a definit un limbaj de manipulare a datelor puternic matematizat, bazat pe teoria ansamblurilor (seturilor), numit DSL/Alpha Prezentul capitol este dedicat unui limbaj teoretic - algebra relaţională - care poate constitui un bun punct de plecare în înţelegerea chestiunilor esenţiale ale celui mai important limbaj dedicat bazelor de date - SQL Caracterizare generală a limbajelor de interogare Gestiunea bazelor de date relaţionale are ca obiectiv principal acoperirea nevoilor informaţionale ale conducerii firmei la toate nivelurile Până la consacrarea SGBDR-urilor, extragerea informaţiilor dorite din baza de date se realiza prin aplicaţii dezvoltate exclusiv cu limbaje procedurale, în care se precizează atât datele dorite, cât şi metodele de căutare şi extragere a acestora Actuala generalizare a SGBDR-urilor se află într-o strânsă relaţie cu elaborarea şi implementarea unor limbaje performante pentru manipularea BD - limbajele de interogare Limbajele relaţionale sunt neprocedurale: utilizatorul defineşte datele ce trebuie extrase din BD, sarcina căutării şi extragerii fiind „rezervată” exclusiv SGBD-ului De asemenea, în unele lucrări, acestea sunt considerate limbaje închise, deoarece o consultare generează o nouă relaţie ce poate fi utilizată, la rândul său, ca argument în alte consultări ş a m d Pornind de la cele două modalităţi de definire a relaţiei, pe de o parte, ca predicat aplicat asupra unor domenii şi, pe de altă parte, ca ansamblu de tupluri, limbajele de manipulare a datelor sunt grupate în două mari categorii: limbaje predicative - fondate pe teoria predicatelor şi limbaje asambliste — fondate pe teoria ansamblurilor (tuplurilor) Limbajele predicative sunt divizate în alte două sub-clase: cele care au la bază calculul relaţional asupra tuplurilor (limbaje orientate pe tupluri) şi cele în care calculul relaţional se aplică asupra domeniilor (limbaje orientate pe domenii) Elementul definitoriu pentru limbajele de manipulare bazate pe calculul predicatelor îl reprezintă noţiunea de variabilă, care poate fi asociată fie tuplurilor, fie domeniilor O altă grupare delimitează limbajele non-grafice de cele grafice Primele permit reprezentarea unei consultări „în linie”, prin dispunerea succesivă a operatorilor, atributelor şi relaţiilor Cele grafice permit redactarea consultării în mod interactiv, prin afişarea pe ecran a unui sistem de meniuri şi elemente de dialog din care opţiunile pot fi selectate şi modificate cu ajutorul mouse-ului (sau claviaturii); în plus, se mai poate opera o delimitare şi pentru limbajele grafice în funcţie de utilizarea explicită sau implicită a variabilelor de domeniu Deşi nu exagerat de recentă, o clasificare încă valabilă (în parte) a limbajelor relaţionale poate fi prezentată ca în figura A „Asambliste”: algebra relaţională (Codd- ), SQL (Chamberlin- ) ' Orientate pe tupluri: ALPHA (Codd- ), QUEL (Stonebraker- ) / Non-grafice: LL (Lacroix şi Pirotte- ), FQL (Pirotte- ) Cu variabile-domeniu explicite: QBE (Zloof- ) v Orientate pe domenii Fără variabile-domeniu explicite: LAGRIF (Miranda- ), FORAL-LP (Senko- ), CUPID (McDonald- ), VGQF (McDonald- ) Figura O clasificare a limbajelor relaţionale Există o serie de caracteristici comune tuturor limbajelor: operatorii relaţionali se aplică relaţiilor luate în întregime, adică tuturor tuplurilor care alcătuiesc relaţiile respective', rezultatul fiecărui operator (rezultatul consultării) este o nouă relaţie ce poate servi ca argument într-o altă consultare ş a m d ; logica operatorilor se bazează pe valorile atributelor, ceea ce constituie, de altminteri, suportul singurului mod de acces în BD întrucât consultările mono- şi multi-relaţii sunt efectuate exclusiv prin compararea valorilor atributelor (definite pe domenii compatibile), accesul total independent de limbaj este asigurat înaintea redactării unei consultări într-un limbaj relaţional trebuie parcursă o fază de analiză, pentru determinarea atributelor rezultatului, legăturilor dintre tabele şi eventualelor condiţii (restricţii) ce trebuie respectate Limbajul algebric relaţional cuprinde două tipuri de operatori: asamblişti - REUNIUNE, INTERSECŢIE, DIFERENŢĂ, PRODUS CARTEZIAN - şi relaţionali - SELECŢIE, PROIECŢIE, JONCŢIUNE şi DIVIZIUNE O altă clasificare distinge operatorii fundamentali, ireductibili (reuniunea, diferenţa, produsul cartezian, selecţia, proiecţia), de cei derivaţi, a căror funcţionalitate poate fi realizată prin combinarea operatorilor fundamentali (intersecţia, joncţiunea, diviziunea) Pentru cele ce urmează se notează cu: t sau r, un tuplu al unei relaţii (linie a unei tabele) şi t(A), un sub-tuplu al relaţiei R, relativ la atributul A (valoarea atributului A în linia t) Algebra, ca şi calculul relaţional, serveşte ca punct de referinţă în caracterizarea unui limbaj ca fiind complet sau incomplet, din punct de vedere relaţional Dacă un limbaj permite exprimarea tuturor operatorilor enumeraţi mai sus şi oferă cel puţin facilităţile algebrei relaţionale, se spune că acesta este un limbaj relaţional complet Mai trebuie amintit că în literatura de specialitate există o multitudine de reprezentări ai operatorilor algebrei relaţionale Notaţia pe care o vom utiliza în cele ce urmează este cea mai simplă şi uşor de înţeles {părerea mea, vorba lui ) Operatorii asamblişti Trei dintre operatorii asamblişti - reuniunea („u”), intersecţia („n”) şi diferenţa („-”) - pot opera numai cu două relaţii unicompatibile Fie R ( Al, A , , An) şi R (Bl, B , , Bm) două relaţii Se spune despre R şi R că sunt unicompatibile dacă: n = m V i e { , , , n}, Ai şi Bi sunt de acelaşi tip sintactic (aceasta nu înseamnă că trebuie să prezinte, neapărat, domenii identice de definire) Relaţiile R şi R din figura sunt unicompatibile deoarece: ambele au acelaşi număr de atribute; atributele A, B, C din R (le putem nota şi Rl A, R B, Rl C) corespund sintactic (sunt de acelaşi tip) atributelor C, D şi E din R (R C, R D, R E) R C D E XYZ XXZ YYX Figura Două relaţii unicompatibile Reuniunea a două relaţii unicompatibile, R şi R , este definită astfel: R u R = {tuplu e R sau t e R }  Conţinutul tabelei-reuniune R este prezentat în figura Primele trei tupluri din rezultat sunt preluate din Rl, iar ultimele două din R R are numai cinci tupluri deoarece un tuplu este comun tabelelor Rl şi R Algebra relaţională elimină automat dublurile (tuplurile identice), astfel încât restricţia de unicitate este asigurată după orice operaţie R R A B C   XYZ    XXZ    YYX    R UR A B c   XYZ    XXZ    YYX    XYZ    XXZ   Figura Reuniunea a două relaţii Există suficiente situaţii informaţionale care fac uz de reuniunea a două tabele Să luăm două exemple: tabelele ce reflectă tranzacţii economice pot fi descompuse (sparte) în funcţie de anul (luna sau cincinalul, deceniul) la care se referă; dacă ne raportăm la baza noastră de date, tabela LINIIFACT poate fi ruptă în alte două: LF , care ar conţine facturile emise în anii şi , şi LINIIFACT, ce conţine numai înregistrări aferente anului calendaristic începând cu , orice situaţie statistică privind vânzările în perioada - , - etc necesită reuniunea celor două tabele, LF şi LINIIFACT pentru a afla care sunt clienţii care au cumpărat cel puţin unul din produsele Produs şi Produs , se poate proceda la reuniunea tabelei ce conţine clienţii care au cumpărat Produs cu tabela clienţilor care au cumpărat Produs Reuniunea este comutativă Singura problemă neclară ar fi legată de numele atributelor în relaţia-rezultat în acest sens, se poate institui regula potrivit căreia numele atributelor relaţiei-reuniune sunt numele primei relaţii participante în operaţie Aceasta nu are importanţă asupra comutativităţii, deoarece conţinutul tabelei-rezultat este identic, indiferent care este prima relaţie enumerată Intersectia t Intersecţia a două relaţii unicompatibile, Rl şi R , poate fi definită astfel: Rl n R = {tuplu t | t e Rl şi t e R } Se notează: R poate fi scrisă mai analitic astfel: ■=> = (termeni) şi/sau (termen ) şi/sau (termenk), unde O termen j = expresiei expresie ^ expresie; sau expresie sunt expresii calculate plecând de la atributele Ai ale relaţiei R => poate fi unul dintre operatorii pentru comparaţie Exemplul Pentru a pune în operă savanta notaţie de mai sus, luăm în discuţie o primă problemă: Care sunt liniile din Rl pentru care valorile atributelor A şi C sunt mai mari decât ? Ajungem, astfel, la notaţia: R AND C > ) Tabela R este prezentată în figura R A B C   YYX    Figura Rezultat-selecţie - exemplul Exemplul Care sunt judeţele din Moldova? Mai întâi se identifică în baza de date tabela (sau tabelele) din care se extrage rezultatul în acest exemplu, aceasta este JUDEŢE Apoi se stabilesc atributele (atributul) asupra cărora se va aplica predicatul de selecţie Se obţine soluţia: R = / / AND DataFact , >, R şi t(Ai) t(Bj)} Joncţiunea este echivalenta unui produs cartezian urmat de o selecţie Joncţiunea definită mai sus este cunoscută în lucrările de specialitate ca theta-joncţiune în lucrul cu BDR se utilizează cu precădere echi-joncţiunea, ce reprezenta un caz particular al theta-joncţiunii, atunci când este operatorul de egalitate („=”) Formal, echi-joncţiunea se defineşte astfel: Rl (Ai = Bj)R ={t|teRl ® R şi t(Ai) = t (Bj)} R A B C  Pvk R R   XYZ  \ A B R C R C D E   XXZ    XYZ   XYZ    YYX    XYZ   YYX    A  XYZ   XXZ     XXZ   XYZ   HI   /  XXZ   YYX   c D E   XXZ   XXZ    XYZ    YYX'   XYZ    YYX    YYX   YYX    XXZ    YYX   XXZ     R= SELECŢIE  (R-, A > r E)     A B R C R C D E    XXZ   XYZ     XXZ   YYX      YYX   XYZ      YYX   YYX      YYX   XXZ    Figura Mecanismul de (theta)joncţionare - exemplul Apelăm şi la o altă notaţie, mai uşor de reprezentat şi suficient de inteligibilă R = R E) va fi obţinut în doi paşi, după cum este descris în figura Exemplul - Echi-joncţiune Operatorul de comparaţie dintre cele două atribute este, obligatoriu, semnul de egalitate R = / / AND DataFact = / / AND DataFact R Tabela R cuprinde toate tuplurile posibile (xi, yj) R R C R - indică (theta)joncţiunea relaţiilor Rl şi R prin predicatul: Rl A > R C Exemple Soluţia de la exemplul : Rl = / / AND DataFact = / / a DataFact o FACTURI> R C, se foloseşte notaţia: Rl TIMES R ) WHERE Rl A > R C pentru joncţiunea naturală lucrurile sunt mai simple; astfel, joncţiunea naturală dintre Rl şi R prin atributul C (atributul comun) se simbolizează pur şi simplu: Rl JOIN R diviziune: Rl DIVIDED BY R Exemple Soluţia de la exemplul : (CLIENŢI WHERE DenCl = "Client SA") [Telefon] Soluţia de la exemplul : ( ( LINIIFACT WHERE NrFact = ) [CodPr] ) INTERSECT ( (LINIIFACT WHERE NrFact = ) [CodPr] ) Soluţia de la exemplul : ( ( JUDEŢE JOIN LOCALITATI ) WHERE Regiune = "Banat" ) Soluţia de la exemplul (((((((( PRODUSE WHERE DenPr = "Produs " ) JOIN LINIIFACT ) [NrFact] ) JOIN FACTURI ) WHERE DataFact >= / / AND DataFact (clistă elemente din tabelă>) unde: listă elemente din tabelă > : : = = | , element al tabelei > : : = = definiţie coloană > | începem cu definiţiile coloanelor care cuprind o serie de opţiuni pentru declararea numelui, tipului, lungimii, precum şi restricţiilor: : : = = nume coloană > [ ] [ ] Pentru crearea unei tabele şi declararea atributelor acesteia, fără nici o referire la restricţii, comanda CREATE TABLE are, în cazul tabelei JUDEŢE, următoarea formă: CREATE TABLE JUDEŢE (Jud CHAR( ) , Judeţ VARCHAR( ), Regiune VARCHAR ( )) întrucât atributele acestei tabele sunt exclusiv de tip şir de caractere, s-au folosit opţiunile CHAR şi VARCHAR CHAR este preferat pentru atributul Jud, deoarece indicativul auto al judeţului este format exclusiv din două litere (cu excepţia Bucureştiului) întrucât denumirile judeţului şi regiunii au lungime variabilă, pentru aceste atribute a fost preferat tipul VARCHAR Pentru ilustrarea şi altor două tipuri de date, prezentăm comanda de creare a tabelei FACTURI: CREATE TABLE FACTURI ( NrFact NUMERIC( ), DataFact DATE, CodCl DECIMAL( ), Obs VARCHAR( ) ) NrFact şi CodCl sunt de tip numeric, în timp ce DataFact de tip dată calendaristică Se mai cuvine de adăugat că unele atribute pot fi iniţializate cu o valoare implicită la adăugarea unei linii în tabela respectivă Clauza este DEFAULT: clauză valoarea implicită > : : = = [ CONSTRAINT ] DEFAULT opţiune valoare implicită > : : = = | | NULL Ultima comandă se poate rescrie astfel: CREATE TABLE FACTURI ( NrFact NUMERIC( ), DataFact DATE DEFAULT SYSDATE, CodCl DECIMAL( ) DEFAULT , Obs VARCHAR( ) ) Ca urmare a clauzei DEFAULT, în orice linie adăugată în tabela FACTURI, valoarea implicită (dacă nu este specificată în comanda INSERT) a DataFact va fi data sistemului (data curentă), iar CodCl se va iniţializa cu valoarea Mai trebuie amintit faptul că unele SGBD-uri, precum VFP, permit calculul valorilor implicite pe baza unei funcţii-utilizator (procedură stocată), iar altele, precum Oracle, permit folosirea secvenţelor în declanşatoare, utile mai ales pentru atribute-cheie, numerice Declararea restricţiilor în SQL se pot declara toate tipurile de restricţii ale unei BDR: valori obligatorii (nenule), unicitate, restricţii referenţiale şi restricţii-utilizator Continuând detalierea formulului general al comenzii CREATE TABLE în sintaxa SQL- : restricţie a coloanei > : : = = NOT NULL | | | Valori nenule Unele atribute, obligatoriu cele din cheia primară, nu pot prezenta valori nule Pentru aceasta, la crearea tabelei şi declararea atributului se foloseşte opţiunea NOT NULL în unele produse (DB , Oracle) trebuie indicate explicit atributele ce nu pot avea valori nule, în timp ce în Visual FoxPro este invers, trebuie declarate atributele susceptibile de valori NULL Şi între Oracle şi DB există o mică deosebire în Oracle, pentru un atribut-cheie nu este obligatorie clauza NOT NULL, în timp ce în DB este Iată noua formă a comenzii pentru crearea tabelei FACTURI: CREATE TABLE FACTURI ( NrFact NUMERIC( ) NOT NULL, DataFact DATE DEFAULT SYSDATE NOT NULL, CodCl DECIMAL( ) DEFAULT NOT NULL, Obs VARCHAR( ) ) Cheie primară/unicitate specificaţie privind unicitatea > : : = = UNIQUE ] PRIMARY KEY Cheia primară a unei relaţii este definită prin clauza PRIMARY KEY, plasată fie imediat după atributul-cheie, fie după descrierea ultimului atribut al tabelei A doua variantă este întrebuinţată cu precădere atunci când cheia primară a tabelei este compusă Pentru atributele de tip cheie candidată se poate folosi clauza UNIQUE, care va asigura respectarea unicităţii valorilor Iată câteva variante de folosire a clauzelor PRIMARY KEY şi UNIQUE: CREATE TABLE FACTURI ( NrFact NUMERIC( ) NOT NULL PRIMARY KEY, DataFact DATE DEFAULT SYSDATE NOT NULL, CodCl DECIMAL( ) DEFAULT NOT NULL, Obs VARCHAR( ) ) CREATE TABLE JUDEŢE ( Jud CHAR( ) PRIMARY KEY, Judeţ VARCHAR( ) NOT NULL UNIQUE, Regiune VARCHAR ( ) ) CREATE TABLE LINIIFACT ( NrFact NUMERIC( ) NOT NULL, Linie SMALLINT NOT NULL, CodPr NUMERIC( ) NOT NULL, Cantitate NUMERIC( ) NOT NULL, PretUnit NUMBER ( ), PRIMARY KEY (NrFact, Linie), UNIQUE (NrFact, CodPr) ) Pentru tabela LINIIFACT, cheia primară este combinaţia de atribute (NrFact, Linie), restricţia de unicitate pentru cuplul (NrFact, CodPr) înseamnă că se interzice ca, pe o factură, un produs să apară repetat Restricţii referenţiale specificaţie referenţială > : : = = [ CONSTRAINT ] REFERENCES [ ( ccoloană referenţiată> ) ] Declararea restricţiilor referenţiale se realizează utilizând clauza FOREIGN KEY Astfel, pentru stabilirea legăturii LINIIFACT-FACTURI comanda de creare are forma: CREATE TABLE LINIIFACT ( NrFact NUMERIC( ) NOT NULL, Linie SMALLINT NOT NULL, CodPr NUMERIC( ) NOT NULL, Cantitate NUMERIC( ) NOT NULL, PretUnit NUMBER ( ), PRIMARY KEY (NrFact, Linie), UNIQUE (NrFact, CodPr), FOREIGN KEY NrFact REFERENCES FACTURI(NrFact), FOREIGN KEY CodPr REFERENCES PRODUSE(CodPr) ) Este drept, şi următoarea variantă este corectă: CREATE TABLE LINIIFACT ( NrFact NUMERIC( ) NOT NULL REFERENCES FACTURI(NrFact), Linie SMALLINT NOT NULL, CodPr NUMERIC( ) NOT NULL REFERENCES PRODUSE(CodPr), Cantitate NUMERIC( ) NOT NULL, PretUnit NUMBER ( ), PRIMARY KEY (NrFact, Linie), UNIQUE (NrFact, CodPr) ) în SQL- se poate specifica şi modul în care va fi păstrată integritatea bazei de date la ştergerea unei linii-părinte sau modificarea unei chei primare ce prezintă mregistran-copil S a interzice ştergerea unor facturi (înregistrări din FACTURI) pentru care exista SS corespondente în LINIIFACT şi, Pe de altă parte, pentru ca la modificarea untn număr de factură (NrFact) în FACTURI sa se modifice automat, in cascada, toate liniile-copil din LINIIFACT, forma comenzii se schimbă în: CREATE TABLE LINIIFACT ( NrFact NUMERIC( ) NOT NULL, Linie SMALLINT NOT NULL, CodPr NUMERIC( ) NOT NULL, Cantitate NUMERIC( ) NOT NULL, PretUnit NUMBER ( ), PRIMARY KEY (NrFact, Linie), UNIQUE (NrFact, CodPr), FOREIGN KEY NrFact REFERENCES FACTURI(NrFact) ON DELETE RESTRICT ON UPDATE CASCADE, FOREIGN KEY CodPr REFERENCES PRODUSE(CodPr) ON DELETE RESTRICT ON UPDATE CASCADE ) Restricţii-utilizator în SGBD-urile actuale, restricţiile-utilizator, denumite şi restricţii de comportament sunt implementate sub forma regulilor de validare la nivel de camp [field vahdation rule), la nivel de înregistrare (record validation rule) sau, eventual, pot fi incluse in declanşatoare (tnggere) definiţie regulă de validare > : : = = [ CONSTRAINT ] CHECK ( ) Cu rezerva că aceste reguli pot avea forme complexe şi pot întrebuinţa elemente avansate de SQL şi/sau extensiile procedurale ale SQL în mediulrespectivprezentămin continuare o regulă de validare pentru atributul DataFact in tabela FACTURI şi o alta pentru atributul Linie în LINIIFACT CREATE TABLE FACTURI ( NrFact NUMERIC( ) NOT NULL PRIMARY KEY, DataFact DATE DEFAULT SYSDATE NOT NULL CHECK (DataFact >= ' / / ' AND DataFact ), CodPr NUMERIC( ) NOT NULL, Cantitate NUMERIC( ) NOT NULL, PretUnit NUMBER ( ), PRIMARY KEY (NrFact, Linie), UNIQUE (NrFact, CodPr), FOREIGN KEY NrFact REFERENCES FACTURI(NrFact) ON DELETE RESTRICT ON UPDATE CASCADE, FOREIGN KEY CodPr REFERENCES PRODUSE(CodPr) ON DELETE RESTRICT ON UPDATE CASCADE ) Ca urmare a clauzei CHECK, data unei facturi nu poate avea valori în afara intervalului august — decembrie , iar atributul Linie trebuie să prezinte valori întregi mai mari ca Crearea tabelelor şi declararea restricţiilor în Oracle Ar fi o întreagă aventură dacă am încerca să discutăm formatul general al comenzii CREATE TABLE în Oracle, şi aceasta jdeoarece, în afară de atribute şi restricţii, comanda permite specificarea unei serii întregi de parametri legaţi de definirea organizării tabelei, spaţiul-tabelă, caracteristicile de stocare, clustere, paralelism, partiţionare etc Astfel încât ne limităm discuţia la câteva considerente generale Fiecărei restricţii (cheie primară, unicitate, regulă la nivel de atribut etc ) i se poate da un nume, lucru util atunci când, la un moment dat (salvări, restaurări, încărcarea BD), vrem să dezactivăm una sau mai multe dintre acestea Pentru a uşura lucrul, se prefixează numele fiecărei restricţii cu tipul său: pk (PRIMARY KEY) pentru cheile primare un (UNIQUE) pentru cheile alternative nn (NOT NULL) pentru atributele obligatorii (ce nu pot avea valori nule) ck (CHECK) pentru reguli de validare la nivel de atribut f k (FOREIGN KEY) pentru cheile străine Am preferat tipul NUMBER pentru atributele numerice, deşi, cel puţin pentru coduri, era mai indicat tipul INTEGER (PLS INTEGER) Pentru şiruri de caractere cu lungime variabilă, Oracle recomandă utilizarea tipului VARCHAR Lucrul cu atribute de tip DATE (dată calendaristică) necesită funcţia de conversie TO DATE () în Oracle nu există tipul de atribute LOG I CAL sau BOOLEAN (doar în PL/SQL o variabilă poate fi declarată BOOLEAN) Atributele unei tabele pot avea definite valori implicite, însă acestea nu pot fi generate prin funcţii-utilizator, proceduri sau secvenţe Declararea unei chei străine se realizează prin clauza REFERENCES în Oracle (cel puţin până la versiunea ) nu există clauză de actualizare în cascadă din tabelele-părinte în cele copil (UPDATE CASCADE), singura opţiune care se poate utiliza fiind ON DELETE CASCADE, utilă pentru ştergerea simultană a unei înregistrări-părinte şi a tuturor înregistrărilor-copil Fireşte, prin mecanismul referenţial, opţiunile implicite sunt ON UPDATE RESTRICT şi ON DELETE RESTRICT în listing este prezentat scriptul Oracle pentru crearea tabelelor şi declararea restricţiilor bazei de date Listing Script Oracle de creare a tabelelor (şi declarare a restricţiilor) DROP TABLE incasfact ;  DROP TABLE incasari ;  DROP TABLE liniifact ;  DROP TABLE facturi ;  DROP TABLE produse ;  DROP TABLE persclienti  DROP TABLE persoane ;  DROP TABLE clienţi ;  DROP TABLE localitati  DROP TABLE judeţe ;   CREATE TABLE judeţe ( jud CHAR( ) CONSTRAINT pk judete PRIMARY KEY CONSTRAINT ck jud CHECK (jud=LTRIM(UPPER(jud) )) , judeţ VARCHAR ( ) CONSTRAINT un judet UNIQUE CONSTRAINT nn judet NOT NULL CONSTRAINT ck judeţ CHECK (judet=LTRIM(INITCAP(judeţ))), regiune VARCHAR ( ) DE FAU LT 'Moldova' CONSTRAINT ck regiune CHECK (regiune IN ('Banat', 'Transilvania', 'Dobrogea', 'Oltenia', 'Muntenia', 'Moldova')) ) ; CREATE TABLE localitati ( codpost CHAR( ) ■ CONSTRAINT pk localitati PRIMARY KEY CONSTRAINT ck codpost CHECK (codpost=LTRIM(codpost)), loc VARCHAR ( ) CONSTRAINT nn loc NOT NULL CONSTRAINT ckJLoc CHECK (loc=LTRIM(INITCAP(loc))), jud CHAR( ) DEFAULT 'IS' CONSTRAINT fk localitati jud REFERENCES judeţe(jud) ) ; CREATE TABLE clienţi ( codcl NUMBER( ) CONSTRAINT pk clienti PRIMARY KEY CONSTRAINT ck codcl CHECK (codcl > ), dencl VARCHAR ( ) CONSTRAINT ck dencl CHECK (SUBSTR(dencl, , ) = UPPER(SUBSTR(dencl, , ))), codfiscal CHAR( ) CONSTRAINT ck codfiscal CHECK (SUBSTR(codfiscal, , ) = UPPER(SUBSTR(codfiscal, , ))), adresa VARCHAR ( ) CONSTRAINT ck adresa clienti CHECK (SUBSTR(adresa, , ) = UPPER(SUBSTR(adresa, , ))) codpost CHAR( ) CONSTRAINT fk clienti localitati REFERENCES localitati(codpost), telefon VARCHAR ( ) ) ; CREATE TABLE persoane ( cnp CHAR( ) CONSTRAINT pk persoane PRIMARY KEY CONSTRAINT ck cnp CHECK (cnp=LTRIM(UPPER(cnp))) nume VARCHAR ( ) CONSTRAINT ck nume CHECK (nume=LTRIM(INITCAP(nume))) prenume VARCHAR ( ) CONSTRAINT ck prenume CHECK (prenume=LTRIM(INITCAP(prenume))), adresa VARCHAR ( ) CONSTRAINT ck adresa persoane CHECK (SUBSTR(adresa, , ) = UPPER(SUBSTR(adresa, , ))) sex CHAR( ) DEFAULT 'B' ' CONSTRAINT ck sex CHECK (sex IN ( F’,’B )) codpost CHAR( ) ' ' CONSTRAINT fk persoane localitati REFERENCES localitati(codpost), telacasa VARCHAR ( ), telbirou VARCHAR ( ), telmobil VARCHAR ( ), email VARCHAR ( ) ) ; CREATE TABLE persclienti ( cnp CHAR( ) CONSTRAINT fk persclienti persoane REFERENCES persoane(cnp), codcl NUMBER( ) CONSTRAINT fk persclienti clienti REFERENCES clienţi(codcl), funcţie VARCHAR ( ) CONSTRAINT ck functie CHECK (SUBSTR(funcţie, ) = UPPER(SUBSTR(funcţie, , ))), CONSTRAINT pk persclienti ^ PRIMARY KEY (cnp, codcl, funcţie) CREATE TABLE produse ( codpr NUMBER( ) CONSTRAINT pk produse PRIMARY KEY CONSTRAINT ck codpr CHECK (codpr > ), denpr VARCHAR ( ) CONSTRAINT ck denpr CHECK (SUBSTR(denpr, , ) = UPPER(SUBSTR(denpr, , ))) um VARCHAR ( ), ' grupa VARCHAR ( ) CHECK (SUBSTR(grupa, , ) = UPPER (SUBSTR(grupa, , ))) procTVA NUMBER( , ) DEFAULT ) ; CREATE TABLE facturi ( nrfact NUMBER( ) CONSTRAINT pk facturi PRIMARY KEY, datafact DATE DEFAULT SYSDATE CONSTRAINT ck datafact CHECK (datafact >= TO DATE(' / / ','DD/MM/YYYY') AND datafact ), codpr NUMBER( ) CONSTRAINT fk liniifact produse REFERENCES produse(codpr), cantitate NUMBER( ), pretunit NUMBER ( ), CONSTRAINT pk liniifact PRIMARY KEY (nrfact,linie) ) ; CREATE TABLE incasari ( codinc NUMBER( ) CONSTRAINT pk incasari PRIMARY KEY, datainc DATE DEFAULT SYSDATE CONSTRAINT ck datainc CHECK (datainc >= TO DATE(' / / ','DD/MM/YYYY') AND datainc = TO DATE(' / / ','DD/MM/YYYY') AND datadoc ), dencl VARCHAR( ) CONSTRAINT ck dencl CHECK (SUBSTR(dencl, , ) = UPPER(SUBSTR(dencl, , ))), codfiscal CHAR( ) CONSTRAINT ck codfiscal CHECK (SUBSTR(codfiscal, , ) = UPPER(SUBSTR(codfiscal, , ) )) , adresa VARCHAR( ) CONSTRAINT ck adresa clienti CHECK (SUBSTR (adresa, , ) = UPPER (SUBSTR (adresa, , ) ) ) , codpost CHAR( ) CONSTRAINT fk cl loc REFERENCES localitati(codpost), telefon VARCHAR(IO) ) ; CREATE TABLE persoane ( cnp CHAR( ) NOT NULL CONSTRAINT pk persoane PRIMARY KEY CONSTRAINT ck cnp CHECK (cnp=LTRIM(UPPER(cnp))), nume VARCHAR( ), prenume VARCHAR( ), adresa VARCHAR( ) CONSTRAINT ck adresa persoane CHECK (SUBSTR(adresa, , ) = UPPER(SUBSTR(adresa, , ))), sex CHAR( ) DEFAULT 'B' CONSTRAINT ck sex CHECK (sex IN ('F','B')), codpost CHAR( ) CONSTRAINT fk pers loc REFERENCES localitati(codpost), telacasa VARCHAR(IO), telbirou VARCHAR(IO), telmobil VARCHAR(IO), email VARCHAR( ) ) ; CREATE TABLE persclienti ( cnp CHAR( ) NOT NULL CONSTRAINT fk perscl pers REFERENCES persoane(cnp), codcl DECIMAL( ) NOT NULL CONSTRAINT fk perscl cl REFERENCES clienţi(codcl), funcţie VARCHAR( ) NOT NULL ' CONSTRAINT ck functie CHECK (SUBSTR(funcţie, , ) = UPPER(SUBSTR(funcţie, , ))), CONSTRAINT pk persclienti PRIMARY KEY (cnp, codcl, funcţie) ) ; CREATE TABLE produse ( codpr DECIMAL( ) NOT NULL CONSTRAINT pk produse PRIMARY KEY CONSTRAINT ck codpr CHECK (codpr > ), denpr VARCHAR( ) CONSTRAINT ck denpr CHECK (SUBSTR(denpr, , ) = UPPER(SUBSTR(denpr, , ))), um VARCHAR( ), grupa VARCHAR( ) CHECK (SUBSTR(grupa, , ) = UPPER(SUBSTR(grupa, , ))), procTVA DECIMAL( , ) DEFAULT ) ; CREATE TABLE facturi ( nrfact DECIMAL( ) NOT NULL CONSTRAINT pk facturi PRIMARY KEY, datafact DATE DEFAULT CURRENT DATE, CONSTRAINT ck datafact CHECK (datafact >= ' / / ' AND datafact ), codpr DECIMAL( ) CONSTRAINT fk lf prod REFERENCES produse(codpr), cantitate DECIMAL(IO), pretunit DECIMAL ( ), CONSTRAINT pk liniifact PRIMARY KEY (nrfact,linie) ) ; CREATE TABLE incasari ( codinc DECIMAL( ) NOT NULL CONSTRAINT pk incasari PRIMARY KEY, datainc DATE CONSTRAINT ck datainc CHECK (datainc >= ' / / ' AND datainc = ' / / ' AND datadoc ), ; dencl CHAR( ) ; CHECK(SUBSTR(dencl, , )=UPPER(SUBSTR(dencl, , ))), ; codfiscal CHAR( ) ; NULL ; CHECK (SUBSTR(codfiscal, , )=; UPPER(SUBSTR(codfiscal, , ))), ; adresa CHAR( ) ; NULL ; CHECK (SUBSTR(adresa, , ) =; UPPER(SUBSTR(adresa, , ))), ; codpost CHAR( ), ; telefon CHAR( ) ; NULL, ; FOREIGN KEY codpost TAG codpost ; REFERENCES localitati TAG codpost ; ) ; CREATE TABLE persoane ( ; cnp CHAR( ) ; PRIMARY KEY ; CHECK (cnp=LTRIM(UPPER(cnp))) ; ERROR 'Codul numeric personal se scrie fara ; spatii la inceput !', ; nume CHAR( ) ; CHECK (nume=LTRIM(PROPER(nume))) ; ERROR 'Prima litera din fiecare cuvint al'+CHR( )+; 'numelui este majuscula; '+CHR( )+; 'restul literelor sunt mici!', ; prenume CHAR( ) ; CHECK (prenume=LTRIM(PROPER(prenume))) ; ERROR 'Prima litera din fiecare cuvint al'+CHR( )+; 'prenumelui este majuscula; '+CHR( )+; 'restul literelor sunt mici!', ; adresa CHAR( ) ; NULL ; CHECK (SUBSTR(adresa, , ) = UPPER(SUBSTR(adresa, , ))) ; ERROR 'Prima litera din adresa este obligatoriu ; maj uscula !', ; sex CHAR( ) DEFAULT 'B' ; CHECK (INLIST(sex,'F','B')) ; ERROR 'Atributul Sex poate avea valorile F ; (de la Femeiesc)'+CHR( )+; 'sau B (de la Bărbătesc) !', ; codpost CHAR( ), ; telacasa CHAR( ) NULL, ; telbirou CHAR( ) NULL, ; telmobil CHAR( ) NULL, ; email CHAR( ) NULL, ; FOREIGN KEY codpost TAG codpost ; REFERENCES localitati TAG codpost ; ) ; CREATE TABLE persclienti ( ; cnp CHAR( ), ; codcl NUMBER( ), ; funcţie CHAR( ) ; CHECK (SUBSTR(funcţie, , ) = UPPER(SUBSTR(funcţie, , ))) ERROR 'Prima litera din funcţie este obligatoriu ; majuscula !', ; PRIMARY KEY cnp+STR(codcl, )+functie TAG primaru, ; FOREIGN KEY cnp TAG cnp REFERENCES persoane TAG cnp, ; FOREIGN KEY codcl TAG codcl REFERENCES clienţi TAG codcl ) ; CREATE TABLE produse ( ; codpr NUMBER( ) ; PRIMARY KEY ; CHECK (codpr > ) ; ERROR 'Codul produsului trebuie sa fie mai mare ; ca zero !', ; denpr CHAR( ) ; CHECK (SUBSTR(denpr, , ) = UPPER(SUBSTR(denpr, , ))) ; ERROR 'Prima litera din denumirea produsului ; este obligatoriu majuscula !', ; um CHAR( ), ; grupa CHAR( ) ; CHECK (SUBSTR(grupa, , ) = UPPER(SUBSTR(grupa, , ))) ; ERROR 'Prima litera din grupa este obligatoriu ; majuscula !', ; procTVA NUMBER( , ) ; DEFAULT ; ) CREATE TABLE facturi ( ; nrfact NUMBER( ) ; PRIMARY KEY, ; datafact DATE ; DEFAULT DATE() ; CHECK (BETWEEN (datafact, { A / / }, {-' / / }) ) ; ERROR 'Baza de date functioneaza in intervalul ; aug - dec !', ; codcl NUMBER( ), ; Obs CHAR( ) NULL, ; FOREIGN KEY codcl TAG codcl REFERENCES clienţi TAG codcl ; ) ; CREATE TABLE liniifact ( ; nrfact NUMBER( ), ; linie NUMBER( ) ; CHECK (linie > ) ; ERROR 'Atributul linie trebuie sa fie mai mare ; ca zero !', ; codpr NUMBER( ), ; cantitate NUMBER( ), ; pretunit NUMBER ( ), ; PRIMARY KEY STR(nrfact, )+STR(linie, ) TAG primaru, ; FOREIGN KEY nrfact TAG nrfact REFERENCES facturi TAG nrfact, ; FOREIGN KEY codpr TAG codpr REFERENCES produse TAG codpr ; ) CREATE TABLE incasari ( ; codinc NUMBER( ) ; PRIMARY KEY, ; datainc DATE ; DEFAULT DATE() ; CHECK (BETWEEN(datainc, ; BETWEEN(datafact,{A / / }, {A / / })) ; ERROR 'Baza de date functioneaza in intervalul ; aug - dec !', ; coddoc CHAR( ) ; CHECK(coddoc=UPPER(LTRIM(coddoc))) ; ERROR 'Codul documentului se scrie cu majuscule I', ; nrdoc CHAR( ), ; datadoc DATE ; DEFAULT DATE() - ; CHECK (BETWEEN(datadoc,; BETWEEN (datafact, {'' / / }, {^ / / }) ) ; ERROR 'Data documentului trebuie sa fie intre ; ian si dec !' ; ) ; CREATE TABLE incasfact ( ; codinc NUMBER( ), ; nrfact NUMBER ( ), ; transa NUMBER( ) ; NOT NULL, ; PRIMARY KEY STR(codinc, )+STR(nrfact, ) TAG primaru, ; FOREIGN KEY codinc TAG codinc ; REFERENCES incasari TAG codinc, ; FOREIGN KEY nrfact TAG nrfact REFERENCES facturi TAG nrfact ; ) ; Nefiind un SGBDR de categoria grea, crearea bazei de date în VFP este un lucru uşor fiind necesară o singură comandă, CREATE DATABASE O opţiune interesantă la crearea tabelelor ţine de faptul că, în afară de declararea restricţiilor, în VFP se poate stabili şi mesajul afişat la violarea restricţiei respective De asemenea, în VFP se indică explicit ce atribute pot avea valori nule (în Oracle şi DB se indică explicit cele care nu pot avea valori NULL) în plus, la atributele de tip numeric (reale), în numărul total de caractere o poziţie (distinctă) se contorizează pentru marca zecimală La declararea cheilor primare compuse, atributele componente trebuie concatenate lucru ce atrage necesitatea conversiei celor de alt tip (numerice, dată calendaristică, logice) în şiruri de caractere Declararea cheilor primare, alternative şi străine în VFP presupune crearea automată a indecşilor de tip PRIMARY, CANDIDATE sau REGULAR Prin clauza TAG se poate da un nume la alegere indexului respectiv Din păcate, declararea cheilor străine nu înseamnă şi instituirea restricţiei referenţiale Aceasta este una dintre cele mai ciudate „găselniţe” VFP Ca urmare, după crearea BD, fie trebuie „umblat” prin Referenţial Integrity Builder şi, astfel, grafic, instituite regulile pentru prezervarea referenţialităţii, fie trebuie create declanşatoare în acest scop (vezi capitolul ) Modificarea structurii tabelelor/restricţilor în Oracle, DB şi VFP Schema unei baze de date reprezintă aspectul constant, invariabil sau, mai bine zis, puţin variabil în timp O bună analiză şi proiectare a aplicaţiei (sistemului) diminuează riscul modificărilor de amploare în structura tabelor şi restricţii, conferind stabilitate bazei şi diminuând sensibil eforturile de întreţinere ulterioară instalării aplicaţiei Cu toate acestea, apariţia unui atribut nou, modificarea lungimii unui atribut sunt probleme de care orice analist/proiectant sau administrator/dezvoltator de aplicaţii şi BD s-a ciocnit cel puţin o dată (pe lună - e o glumă, fireşte!) La aceste situaţii putem adăuga operaţiunile diverse - încarcărea bazei dintr-o altă aplicaţie, salvări, restaurări etc - operaţiuni în care este necesară dezactivarea temporară a unor restricţii şi reactivarea lor ulterioară în plus, destui practicieni obişnuiesc să creeze mai întâi toate tabelele (declararea atributelor) şi apoi să definească, printr-un script special, toate restricţiile bazei Astfel încât SQL prezintă o comandă dedicată modificării structurii bazei de date: ALTER TABLE ALTER TABLE unde: acţiune modificatoare a tabelei > : : = = ADD [COLUMN] I ALTER [COLUMN] | DROP [COLUMN] ADD DROP CONSTRAINT comportament la ştergere > Comportamentul la ştergere se referă la prohibirea sau propagarea în cascadă a ştergerii în înregistrările/tabelele-copil: comportament la ştergere > : : = = RESTRICT | CASCADE Adăugarea unui nou atribut Adăugarea atributului DataNast (data naşterii) în tabela PERSOANE se realizează identic în toate cele trei produse, DB /Oracle/VFP: ALTER TABLE PERSOANE ADD DataNast DATE Ştergerea unui atribut Curios sau nu, nici DB , nici Oracle nu permit ştergerea unui atribut prin ALTER TABLE, în schimb, VFP este mai generos: ALTER TABLE PERSOANE DROP COLUMN DataNast Ba chiar, în VFP un atribut se poate şi redenumi: ALTER TABLE PERSOANE RENAME COLUMN DataNast TO DataNaşterii Modificarea tipului/lungimii unui atribut DB permite modificarea lungimii numai pentru atributele de tip VARCHAR Pentru a creşte dimensiunea atributului Nume în tabela PERSOANE la de caractere se foloseşte: ALTER TABLE PERSOANE ALTER Nume SET DATA TYPE VARCHAR( ) în Oracle, modificarea tipului unui atribut se poate face astfel: din CHAR în VARCHAR sau VARCHAR; din VARCHAR sau VARCHAR în CHAR, dar numai dacă respectivul atribut conţine valoarea NULL în toate liniile tabelei sau dacă nu se modifică şi lungimea atributului Lungimea poate fi mărită pentru orice atribut fără probleme; în schimb, micşorarea sa poate avea loc numai când valorile atributului respectiv sunt NULL Pentru atingerea aceluiaşi scop ca în precendenta ALTER TABLE din DB , în Oracle comanda are forma: ALTER TABLE PERSOANE MODIFY (Nume VARCHAR ( )) Visual FoxPro este mai puţin pretenţios la modificarea lungimii atributelor; acestea pot fi deopotrivă mărite sau micşorate; bineînţeles, la micşorare, trebuie avută în vedere trunchierea ce operează inevitabil ALTER TABLE PERSOANE ALTER COLUMN Nume CHAR( ) dar şi ALTER TABLE PERSOANE ALTER COLUMN Nume CHAR( ) Adăugarea/modificarea valorii implicite Declararea valorii implicite a unui atribut în DB este posibilă numai la crearea tabelei sau la adăugarea atributului în Oracle lucrurile sunt mai simple Dacă se doreşte ca în liniile ce urmează a fi adăugate valoarea implicită a atributului Sex să fie ‘F’ (de la Femeiesc), comanda utilizată va fi: ALTER TABLE PERSOANE MODIFY (Sex DEFAULT ’F') Pentru anularea oricărei valori implicite se poate folosi: ALTER TABLE PERSOANE MODIFY (Sex DEFAULT NULL) Bineînţeles, atributele pentru care se declară NULL ca valoare implicită trebuie să „suporte” această (meta)valoare Şi VFP pemite modificarea valorilor implicite, prin: ALTER TABLE PERSOANE ALTER COLUMN Sex SET DEFAULT F' NULL şi neNULL ■ Pentru unele atribute poate fi instituită la crearea tabelei obligativitatea valorilor nenule în timp, aceasta poate fi modificată într-un sens sau în celălalt DB nu este prea flexibil în această privinţă, în schimb Oracle şi VFP da Interzicerea valorilor nule pentru atributul Sex se realizează astfel: în Oracle: ALTER TABLE PERSOANE MODIFY (Sex NOT NULL) în VFP: ALTER TABLE PERSOANE ALTER COLUMN Sex NOT NULL Invers, pentru a permite valori NULL pentru acelaşi atribut: în Oracle: ALTER TABLE PERSOANE MODIFY (Sex NULL) în VFP: ~~ — — — ALTER TABLE PERSOANE ALTER COLUMN Sex NULL A dăugarea/anularea restricţiilor Toate restricţiile: cheie primară - PRIMARY KEY, unicitate - UNIQUE, referenţială - FOREIGN KEY, de comportament - CHECK pot fi declarate ulterior creării tabelei şi, bineînţeles, anulate la un moment dat Spre exemplu, formatul general al comenzii pentru dezactivarea cheii primare, comun celor trei SGBD-uri, este: ALTER TABLE PERSOANE DROP PRIMARY KEY De remarcat că, din cele trei produse, numai Oracle s-a „opus” vehement comenzii, motivând că există restricţii referenţiale declarate pe baza acestei chei primare Pentru reinstituirea cheii primare a tabelei PERSOANE comanda are forma: ALTER TABLE PERSOANE ADD PRIMARY KEY (CNP) Analog, prin ADD şi DROP pot fi instituite/anulate şi celelalte tipuri de restricţii Pentru- o mai simplă referire, este utilă folosirea clauzei CONSTRAINT (în DB şi Oracle) prin care se acordă un nume-utilizator fiecărei restricţii Altminteri, pentru aflarea numelui restricţiei ce trebuie anulată este necesară consultatea catalogului sistem Ştergerea tabelelor Comanda DROP TABLE şterge o comandă din baza de date Sintaxa acesteia nu ridică probleme deosebite: DROP unde: comportament la ştergere > : : = = RESTRICT | CASCADE Inserarea, modificarea, ştergerea liniilor SQL prezintă comenzi dedicate modificării conţinutului unei tabele, înţelegând prin aceasta trei acţiuni prin care se actualizează baza: adăugarea de noi linii la cele existente în tabelă, ştergerea unor linii, modificarea valorii unui atribut Adăugarea unei linii Comanda SQL de adăugare de noi linii este INSERT, care are, în modul de lucru cel mai puţin pretenţios, următorul format: INSERT INTO tabelă [ (atributl, atribut , )] VALUES (valoare atributl, valoare atribut , ) In ceea ce priveşte scriptul de populare a tabelelor bazei de date cu valorile prezentate în primul capitol, diferenţele dintre DB , Oracle şi VFP sunt minime, aşa încât nu prezentăm decât varianta Oracle din listingul INSERT INTO persoane VALUES ( 'CNP ', 'Lazar', 'Caraion', 'M Eminescu, ', 'B',' ', ' ', NULL, ' ', NULL) ; INSERT INTO persoane VALUES ('CNP ', 'I Creanga, bis', ’B', ' ', NULL, NULL) ; INSERT INTO persoane VALUES ('CNP ', 'Vase', 'Simona', 'M Eminescu, ', 'F', ' ', NULL, ' ', ' ', NULL) ; INSERT INTO persoane VALUES ('CNP ', 'Popa', 'Ioanid', 'I Ion,-B H , Sc C, Ap ', 'B', ' ', ' ', ' ', NULL, NULL) ; INSERT INTO persoane VALUES ('CNP ', 'Bogacs', 'Ildiko', 'I V Viteazu, ', 'F', ' ', ' ', ' ', ' ', NULL) ; INSERT INTO persoane VALUES ( 'CNP ', 'loan', 'Vasilica', 'Gării, B B , Sc A, Ap l', 'F', ' ', ' ', ' ', ' ', NULL) ; INSERT INTO persclienti VALUES ('CNP ', INSERT INTO persclienti VALUES ('CNP ', INSERT INTO persclienti VALUES ( 'CNP ', INSERT INTO persclienti VALUES ('CNP ', INSERT INTO persclienti VALUES ('CNP ', INSERT INTO persclienti VALUES ( 'CNP ', INSERT INTO persclienti VALUES ('CNP ', INSERT INTO persclienti VALUES ( CNP ', INSERT INTO persclienti VALUES ('CNP ', INSERT INTO produse VALUES ( , 'Produs INSERT INTO produse VALUES ( , 'Produs INSERT INTO produse VALUES ( , 'Produs INSERT INTO produse VALUES ( , 'Produs INSERT INTO produse VALUES ( , 'Produs 'Director general'); 'Director general'); 'Sef aprovizionare'); 'Sef aprovizionare'); 'Director financiar') 'Director general'); 'Sef aprovizionare'); 'Director financiar'), 'Sef aprovizionare'); ','buc', 'Tigari', ) ','kg', 'Bere', ) ; ','kg', 'Bere', ) ; ',' ', 'Dulciuri', ) ','buc', 'Tigari', ) INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY') , ); INSERT INTO facturi VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), , 'Probleme cu transportul'); INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), ); INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), ); INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), ); INSERT INTO facturi VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), , 'Preţul propus iniţial a fost modificat'); INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), ); INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), ); INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), ); INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), ) INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), ) INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), ) INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  ) ;  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  ) ;  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO liniifact VALUES ( ,  ,  ,  ,  )  INSERT INTO incasari VALUES  ,       TO DATE(' / / ','DD/MM/YYYY'), 'OP', ' ', TO DATE(' / / ','DD/MM/YYYY')) ; INSERT INTO incasari VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), 'CHIT', ' ', TO DATE(' / / ','DD/MM/YYYY')) ; INSERT INTO incasari VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), 'OP', ' ', TO DATE(' / / ','DD/MM/YYYY')) ; INSERT INTO incasari VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), 'CEC', ' ', TO DATE(' / / ','DD/MM/YYYY')) ; INSERT INTO incasari VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), 'OP', ' ', TO DATE(' / / ','DD/MM/YYYY')) ; INSERT INTO incasari VALUES ( , TO DATE(' / / ','DD/MM/YYYY'), 'OP', ' ', TO DATE(' / / ','DD/MM/YYYY')) ; INSERT INTO incasfact VALUES ( , , ) ; INSERT INTO incasfact VALUES ( , , ) ; INSERT INTO incasfact VALUES ( , , ) ; INSERT INTO incasfact VALUES ( , , ) ; INSERT INTO incasfact VALUES ( , , ) ; INSERT INTO incasfact VALUES ( , , ) ; INSERT INTO incasfact VALUES ( , , ) ; INSERT INTO incasfact VALUES ( , , ) ; INSERT INTO incasfact VALUES ( , , ) ; COMMIT ; Ordinea valorilor din clauza VALUES trebuie să fie identică cu cea declarată la crearea (sau modificarea structurii) tabelelor Modificarea este posibilă numai prin enumerarea, după numele tabelei, a atributelor ce vor primi valorile specificate Pentru tabelele CLIENŢI şi FACTURI au fost incluse în clauza VALUES mai puţine valori decât atributele tabelei Este obligatorie, în aceste cazuri, precizarea atributelor care vor primi valorile în Oracle şi DB , restul, adică cele nespecificate, vor avea, pe liniile respective, valori NULL în VFP, acestea sunt completate cu zero/spaţii (funcţia EMPTY () întoarce T , în timp ce ISNULL () F ) O problemă în VFP ţine de lucrul cu atribute de tip dată calendaristică Listingul prezintă, în acest sens, un extras din programul de populare a bazei de date, şi anume comenzile INSERT pentru tabela FACTURI Listing Constante de tip dată calendaristică în VFP INSERT INTO facturi (nrfact, datafact, codcl) VALUES ( ,; {^ / / }, ) INSERT INTO facturi VALUES ( , {A / / }, , ; 'Probleme cu transportul', ) INSERT INTO facturi (nrfact, datafact, codcl) ; VALUES ( , {A / / }, ) INSERT INTO facturi (nrfact, datafact, codcl) ; VALUES ( , {A / / }, ) INSERT INTO facturi (nrfact, datafact, codcl) ; VALUES ( , {"' / / }, ) INSERT INTO facturi VALUES ( , {A / / }, ; 'Preţul propus iniţial a fost modificat', ) INSERT INTO facturi (nrfact, datafact, codcl) ; VALUES ( , {A / / }, ) INSERT INTO facturi (nrfact, datafact, codcl) ; VALUES ( , {A / / }, ) INSERT INTO facturi (nrfact, datafact, codcl) ; VALUES ( , {A / / }, ) INSERT INTO facturi (nrfact, datafact, codcl) ; VALUES ( , {A / / }, ) INSERT INTO facturi (nrfact, datafact, codcl) ; VALUES ( , {A / / }, ) INSERT INTO facturi (nrfact, datafact, codcl) ; VALUES ( , {A / / }, ) Comanda INSERT permite şi adăugarea unor linii rezultate dintr-o consultare SQL (SELECT) Aici apar câteva diferenţe între VFP, Oracle şi DB , pe care le vom discuta în capitolul Ştergerea liniilor Comanda SQL pentru ştergerea uneia sau mai multor linii dintr-o tabelă este DELETE Formatul general este: DELETE FROM nume-tabelă WHERE predicat Din tabelă vor fi şterse toate liniile care îndeplinesc condiţia specificată în predicatul din clauza WHERE Exemplul Să se elimine din tabela FACTURI factura cu numărul DELETE FROM FACTURI WHERE NrFact = Varianta prezentată funcţionează în toate cele trei SGBD-uri Dacă pentru această factură există întegistrări-copil în LINIIFACT sau INCASFACT, SGBD-ul ţine cont de opţiunea declarată la crearea tabelei Dacă s-a specificat (implicit sau explicit) ON DELETE RESTRICT, ştergerea este interzisă în cazul ON DELETE CASCADE sunt şterse, o dată cu linia din FACTURI, toate liniile-copil din LINIIFACT şi INCASFACT Exemplul Să se elimine din baza de date toate judeţele din Moldova DELETE FROM JUDEŢE WHERE Regiune = 'Moldova' Ca şi în cazul comenzii INSERT, pot fi şterse linii pe baza unei condiţii formulate printr-o subconsultare SQL, opţiune ce va fi prezentată în capitolul Modificarea valorilor unor atribute Pentru a modifica valoarea unuia sau mai multor atribute pe una sau mai multe linii dintr-o tabelă, se foloseşte comanda UPDATE cu formatul general (simplificat): UPDATE tabelă SET atributl = expresiei [, atribut = expresie ] WHERE predicat Modificarea se va produce pe toate liniile tabelei care îndeplinesc condiţia formulată prin predicat Exemplul Noul număr de telefon al clientului ce are codul este - Să se opereze modificarea în baza de date Se actualizează atributul Telefon din tabela CLIENŢI: UPDATE CLIENŢI SET Telefon = ' - ' WHERE CodCl = Exemplul In cadrul unei noi relaxări fiscale, se decide creşterea procentului TVA de la % la % pentru toate produsele Atributul modificat este ProcTVA din tabela PRODUSE, pe toate liniile: UPDATE PRODUSE SET ProcTVA = Capitolul ELEMENTE DE BAZĂ ALE INTEROGĂRILOR SQL Lucrarea de faţă este dedicată preponderent modalităţilor prin care, pornind de la o schemă relaţională, pot fi obţinute diverse informaţii dintr-o bază de date Procesul se numeşte interogare, iar formularea unei interogări înseamnă redactarea unei fraze SELECT Prezentul capitol tratează fundamentele redactării frazelor SELECT şi cele mai „populare" clauze ale acesteia Principalele clauze ale frazei SELECT O frază SELECT are un format pe cât de simplu, pe atât de flexibil Cele trei clauze principale sunt SELECT, FROM şi WHERE, dintre care numai primele două sunt obligatorii Pentru început,"vomTâce o paralelă cu operatorii algebrei relaţionale prezentaţi în capitolul Selecţia şi proiecţia Clauza SELECT corespunde operatorului proiecţie din algebra relaţională, fiind utilizată pentru desemnarea listei de atribute (coloanele) din rezultat Clauza FROM este cealn care— sunt enumerate relaţiile din care vor fi extrase informaţiile aferente consultării Prin WHERE' se desemnează predicatul selectiv al algebrei relaţionale, relativ la atribute ale relaţiilor care" apar în clauza FROM La modul general (şi simplist), o consultare simplă în SQL poate fi prezentată astfel: SELECT CI, C , , Cn frcSm RÎ R , T T~ "WHEKHP P - Prin exeeuţia unei fraze SELECT se obţine un rezultat de formă tabelară Acesta poate fi o listă (text), o tabelă propriu-zisă sau o tabelă temporară (care, de obicei, nu poate fi actualizată), dar şi o tabelă derivată (imagine) Uneori rezultatul poate fi obţinut şi ca o variabilă masiv (tablou) Ci - reprezintă coloanele (care sunt atribute sau expresii de atribute) rezultat; Fţj - sunt relaţiile ce trebuie parcurse pentru obţinerea rezultatului; P - este predicatul (condiţia) simplu sau compus ce trebuie îndeplinit de tupluri pentru a fi incluse în rezultat '' " " - Atunci când clauza WHERE este omisă, se consideră implicit că predicatul P are valoarea logică „adevărat”, astfel încât vor fi incluse în rezultat toate liniile din tabela, sau produsul cartezian al tabelelor, enumerată/enumerate în clauza FROM Dacă, în locul coloanelor CI, C , Cn, apare simbolul *, rezultatul va fi alcătuit din toate coloanele (atributele) relaţiilor specificate în clauza FROM De asemenea, atributele rezultatului preiau numele din tabela/tabelele specificate în FROM Schimbarea numelui se realizează prin clauza AS în capitolul era subliniată echivalenţa noţiunilor relaţie-tabelă Conform restricţiei de unicitate, într-o relaţie nu pot exista două linii identice în SQL, tabela obţinută dintr-o consultare poate conţine două sau mai multe tupluri identice Spre deosebire de algebra relaţională, în SQL nu se elimină automat tuplurile identice fdublurilej din rezultat Pentru aceasta este necesară utilizarea opţiunii DISTINCT: SELECT DISTINCT CI, C , Cn FRoM"*RT R ", , “Km* WfiERE P în concluzie, o frază SELECT, în forma în care a fost prezentată, corespunde: unei selecţii algebrice (clauza WHERE P) unei proiecţii (SELECT Ci) unui produs cartezian (FROM - Rl ® R ® Rm) şi conduce la obţinerea unui rezultat cu n coloane, fiecare coloană fiind: un atribut din Rl, R , , Rm sau expresie calculată pe baza unor atribute din Rl, R , , Rm Vom trece în SQL câteva interogări din algebra relaţională, pe baza exemplelor din capitolul Exemplul - selecţie SELECT * '—'FROM”TCl WHERE A > AND C > Exemplul - selecţie (Care sunt judeţele din Moldova?) SELECT * FROM JUDEŢE WHERE Regiune = "Moldova" Exemplul - selecţie (Care sunt facturile emise în perioada - august ?) Formatul standard al unei constante de tip datâ calendaristică este YYYY-MM-DD, aşa încât o interogare în SQL- poate avea forma: SELECT * FROM FACTURI WHERE DataFact >= ' / / ' AND DataFact , >, = R E iar pentru echi-joncţionarea din exemplul (figura ): SELECT * FROM Rl, R WHERE Rl A = R E Joncţiunea naturală poate fi realizată numai prin specificarea numelor atributelor în clauza SELECT a frazei de interogare în standardul SQL- şi în implementările SQL ale multor SGBD-uri se poate folosi o variantă mai elegantă, ţinând seama că tot ce înseamnă theta- şi echi-joncţiune reprezintă, pentru SQL, INNER JOIN (joncţiune internă) Prin urmare, cele două soluţii de mai sus pot fi rescrise după cum urmează: SELECT * FROM Rl INNER JOIN R ON Rl A >= R E respectiv SELECT * FROM Rl INNER JOIN R ON Rl A >= R E Surprinzător, cel puţin pentru mine, este că Oracle (Oracle ) nu are implementată încă această sintaxă, astfel încât, de aici încolo, toate variantele ce utilizează INNER JOIN operează în DB şi VFP, nu însă şi în Oracle Reluăm, pentru comparaţie, exemple din algebra relaţională Exemplul (Să se obţină, pentru fiecare localitate: codul poştal, denumirea, indicativul şi denumirea judeţului şi regiunea din care face parte) Varianta (generală): SELECT CodPost, Loc, LOCALITATI Jud, Judeţ, Regiune FROM LOCALITATI, JUDEŢE WHERE LOCALITATI Jud'= JUDEŢE Jud Varianta (exclusiv Oracle): SELECT CodPost, Loc, LOCALITATI Jud, Judeţ, Regiune FROM LOCALITATI INNER JOIN JUDEŢE ON LOCALITATI Jud = JUDEŢE Jud Numai atributul Jud a fost prefixat de numele tabelei din care provine Prefixarea este obligatorie atunci când câmpul există în două sau mai multe dintre tabelele enumerate în clauza FROM Exemplul (Care sunt localităţile din Banat?) Varianta (generală): SELECT CodPost, Loc, LOCALITATI Jud, Judeţ, Regiune FROM LOCALITATI, JUDEŢE WHERE LOCALITATI Jud = JUDEŢE Jud AND Regiune='Banat' în clauza WHERE, predicatului de selecţie pentru realizarea joncţiunii i s-a adăugat secvenţa de test a regiunii Varianta (exclusiv Oracle): SELECT CodPost, Loc, LOCALITATI Jud, Judeţ, Regiune FROM LOCALITATI INNER JOIN JUDEŢE ON LOCALITATI Jud = JUDEŢE Jud WHERE Regiune='Banat' Avantajul celei de-a doua variante ţine de separarea condiţiei ce ţine de regiune, de condiţia legată de joncţiunea propriu-zisă Exemplul (In ce zile s-a vândut produsul cu denumirea „ Produs ”?) Varianta (generală): SELECT DISTINCT DataFact FROM PRODUSE, LINIIFACT, FACTURI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND DenPr = 'Produs ' Varianta (exclusiv Oracle): SELECT DISTINCT DataFact FROM PRODUSE INNER JOIN LINIIFACT ON PRODUSE CodPr = LINIIFACT CodPr INNER JOIN FACTURI ON LINIIFACT Nrfact = FACTURI NrFact WHERE DenPr = 'Produs ' De notat folosirea clauzei DISTINCT pentru eliminarea eventualelor dubluri Exemplul (In ce judeţe s-a vândut produsul cu denumirea „Produs ” în perioada - august ?) Varianta (generală): SELECT DISTINCT Judeţ FROM PRODUSE, LINIIFACT, FACTURI, CLIENŢI, LOCALITATI, JUDEŢE WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND FACTURI CodCl = CLIENŢI CodCl AND CLIENŢI CodPost = LOCALITATI CodPost AND LOCALITATI Jud = JUDEŢE Jud AND DenPr = 'Produs ' AND DataFact BETWEEN ' / / ' AND ' / / ' Varianta (exclusiv Oracle - atenţie la constantele de tip dată calendaristică!): SELECT DISTINCT Judeţ FROM PRODUSE INNER JOIN LINIIFACT ON PRODUSE CodPr = LINIIFACT CodPr INNER JOIN FACTURI ON LINIIFACT Nrfact = FACTURI NrFact INNER JOIN CLIENŢI ON FACTURI CodCl = CLIENŢI CodCl INNER JOIN LOCALITATI ON CLIENŢI CodPost = LOCALITATI CodPost INNER JOIN JUDEŢE ON LOCALITATI Jud = JUDEŢE Jud WHERE DenPr = 'Produs ' AND DataFact BETWEEN ' / / ' AND ' / / ' Şi în acest exemplu este recomandată folosirea clauzei DISTINCT Exemplul (In ce zile s-au vândut şi produsul cu denumirea ,, Produs I", şi cel cu denumirea „ Produs ”?) Soluţie - varianta (nu funcţionează în VFP): SELECT DISTINCT DataFact FROM PRODUSE, LINIIFACT, FACTURI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND DenPr = 'Produs ' INTERSECT SELECT DISTINCT DataFact FROM PRODUSE, LINIIFACT, FACTURI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND DenPr = 'Produs ' Soluţie - varianta (SQL- şi DB ): SELECT DISTINCT DataFact FROM PRODUSE INNER JOIN LINIIFACT ON PRODUSE CodPr = LINIIFACT CodPr INNER JOIN FACTURI ON LINIIFACT Nrfact = FACTURI NrFact WHERE DenPr = 'Produs ' INTERSECT SELECT DISTINCT DataFact FROM PRODUSE INNER JOIN LINIIFACT ON PRODUSE CodPr = LINIIFACT CodPr INNER JOIN FACTURI ON LINIIFACT Nrfact = FACTURI NrFact WHERE DenPr = 'Produs ' Pentru variantele soluţiei avem nevoie de ceea ce se numeşte joncţiunea tabelei cu ea însăşi, lucru pe care îl vom discuta în paragraful următor Exemplul (Ce clienţi au cumpărat şi „ Produs ”, şi „ Produs ”, dar nu au cumpărat „ Produs ”?) Soluţia Oracle (şi SQL- şi DB , dacă se înlocuieşte MINUS cu EXCEPT): SELECT DISTINCT DenCl FROM PRODUSE, LINIIFACT, FACTURI, CLIENŢI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND FACTURI CodCl = CLIENŢI CodCl AND DenPr = 'Produs ' INTERSECT SELECT DISTINCT DenCl FROM PRODUSE, LINIIFACT, FACTURI, CLIENŢI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND FACTURI CodCl = CLIENŢI CodCl AND DenPr = 'Produs ' MINUS SELECT DISTINCT DenCl FROM PRODUSE, LINIIFACT, FACTURI, CLIENŢI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND FACTURI CodCl = CLIENŢI CodCl AND DenPr = 'Produs ' Sinonime locale şi joncţiunea unei tabele cu ea însăşi Lucrul cu nume lungi de tabele şi atribute are marele avantaj al lejerităţii la citire şi înţelegerii rapide a logicii de derulare a interogării în schimb, suficienţi informaticieni nu agreează risipa de caractere (şi, implicit, de timp şi nervi) presupuse de redactările „logoreice” Ambele părţi au dreptate în oarecare măsură (sesizaţi sindromul rabinului!) Astfel încât în frazele SELECT, tabelelor li se pot asocia sinonime sau aliasuri mai scurte Pentru ilustrare, ultima interogare se poate rescrie astfel: SELECT DISTINCT DenCl FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C WHERE P CodPr = LF CodPr AND LF Nrfact = F NrFact AND F CodCl = C CodCl AND DenPr = 'Produs ' INTERSECT SELECT DISTINCT DenCl FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C WHERE P CodPr = LF CodPr AND LF Nrfact = F NrFact AND F CodCl = C CodCl AND DenPr = 'Produs ' MINUS SELECT DISTINCT DenCl FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C WHERE P CodPr = LF CodPr AND LF Nrfact = F NrFact AND F CodCl = C CodCl AND DenPr = 'Produs ' Tabelei PRODUSE i s-a asociat sinonimul P, LINIIFACT LF, FACTURI F, iar pentru CLIENŢI C Sinonimele prefixează (când este necesar) numele atributelor în clauzele SELECT şi WHERE (eventual ORDER BY, GROUP BY) Dacă pe calculatorul pe care procesez în acest moment documentul opţiunea WordCount funcţionează rezonabil, atunci luăm de bune următoarele cifre: varianta fără sinonime numără de caractere, în timp ce ultima este alcătuită din Există situaţii în care utilizarea sinonimelor n-are nimic de-a face cu lenea/comoditatea sau depresiile nervoase în afara interogărilor corelate pe care le vom discuta într-un capitol viitor, o operaţiune în care musai trebuie folosite sinonimele este joncţionarea tabelei cu ea însăşi Revenim la exemplul din algebra relaţională: Ce facturi au fost emise în aceeaşi zi cu factura ? Este, probabil, cel mai bun exemplu pentru prezentarea subconsultărilor; noi însă ne vom servi acum de acest caz spre a introduce noul tip de joncţiune SELECT F NrFact FROM FACTURI FI, FACTURI F WHERE FI DataFact = F DataFact AND FI NrFact= Joncţiunea tabelei cu ea însăşi înseamnă, de fapt, joncţiunea a două instanţe ale tabelei respective Rezultatul joncţiunii FI cu F este o tabelă „gospodărească”, după cum se observă în figura SELECT * FROM FACTURI F , FACTURI F WHERE F DataFact-F DataFaa FI NrFact Fl DataFact Fl CodCI Fl Obs F NtFart F DataFact F CodCl F bs    -Aug-     -Auq-      -Auq-  Probleme cu transportul   -Auq-      -Auq-     -Auq-      -Auq-     -Auq-      -Auq-     -Auq-  Probleme cu transportul    -Auq-  Probleme cu transportul   -Auq-  Probleme cu transportul    -Auq-     -Auq-  Probleme cu transportul    -Auq-     -Auq-  Probleme cu transportul    -Auq-     -Auq-      -Auq-  Probleme cu transportul   -Auq-      -Auq-     -Auq-      -Auq-     -Auq-      -Auq-     -Auq-      -Auq-  Probleme cu transportul   -Auq-      -Auq-     -Auq-      -Auq-     -Auq-      -Auq-     -Auq-QO      -Auq-  Preţul propus iniţial a fost modificat   -Auq-      -Auq-     -Auq-  Preţul propus iniţial a fost modificat    -Auq-  Preţul propus iniţial a fost modificat   -Auq-OO  Preţul propus iniţial a fost modificat    -Auq-     -Auq-      -Auq-     -Auq-     /-Auq-     -Auq-OO      -Auq-OO     -Auq-OO     /-Auq-     -Auq-OO      -Auq-OO     -Auq-OO      -Auq-     -Auq-OO      -Auq-     -Auq-OO      -Auq-     -Auq-OO      -Auq-     -Auq-OO      -Auq-     -Auq-OO      -Auq-     -Auq-OO      -Auq-     -Auq-OO      -Auq-OO     -Auq-OO      -Auq-     -Auq-OO      -Auq-OO     -Auq-OO      -Auq-OO     -Auq-OO      -Auq-OO     -Auq-OO     Figura Joncţiunea a două instanţe ale tabelei FACTURI după DataFact Asupra acestui rezultat intermediar se aplică predicatul de selecţie suplimentar, FI NrFact = , rezultatul fiind mult mai puţin impresionant - vezi figura NRFACT DATAFACT CODCL OBS NRFACT DATAFACT CODCL OBS    -AUG-     -AUG-      -AUG-     -AUG-     -AUG-     -AUG-      -AUG-     -AUG-     Figura Rezultatul final a! interogării - exemplul O altă variantă, cea care nu funcţionează în Oracle , se prezintă astfel: SELECT F NrFact FROM FACTURI FI INNER JOIN FACTURI F ON Fl DataFact = F DataFact WHERE FI NrFact= Ca piatră de încercare, revenim la a doua soluţie formulată în algebra relaţională la exemplul : în ce zile s-au vândut şi produsul cu denumirea „ Produs ”, şi cel cu denumirea „ Produs ’’? Joncţionăm o instanţă obţinută prin joncţiunea PRODUSE-LINIIFACT-FACTURI (în care DenPr = ' Produs ') cu o altă instanţă a aceleiaşi combinaţii (în care DenPr = 'Produs ') Soluţie - varianta (generală): SELECT DISTINCT FI DataFact FROM PRODUSE PI, LINIIFACT LF , FACTURI FI, PRODUSE P , LINIIFACT LF , FACTURI F WHERE PI CodPr = LF CodPr AND LF NrFact = Fl NrFact AND (PI DenPr = 'Produs ') AND P CodPr = LF CodPr AND LF NrFact = F NrFact AND (P DenPr = 'Produs ') AND FI DataFact=F DataFact Soluţie - varianta (non-Oracle): SELECT DISTINCT Fl DataFact FROM PRODUSE PI INNER JOIN LINIIFACT LF ON PI CodPr = LF CodPr INNER JOIN FACTURI FI ON LF NrFact = Fl NrFact INNER JOIN FACTURI F ON FI DataFact=F DataFact INNER JOIN LINIIFACT LF ON LF NrFact = F NrFact INNER JOIN PRODUSE P ON LF CodPr = P CodPr WHERE PI DenPr = 'Produs ' AND P DenPr = 'Produs ' Nici nu se putea încheiere mai triumfătoare pentru aşa un paragraf glorios Funcţii-agregat: COUNT, SUM, ÂVG, MIN, MAX Formatul general al unei fraze SELECT ce conţine funcţii-agregat este: SELECT funcţia-predefinităl, , funcţia-predefinităN FROM listă-tabele WHERE condiţii în lipsa opţiunii GROUP BY (vezi paragraful următor), dacă în clauza SELECT este prezentă o fimcţie-agregat, rezultatul va conţine o singură linie Funcţia COUNT Funcţia COUNT contorizează valorile nenule ale unei coloane sau numărul de linii dintr-un rezultat al unei interogări, altfel spus, în rezultatul unei consultări, COUNT numără câte valori diferite de NULL are o coloană specificată sau câte linii sunt Câţi clienţi are firma? SELECT COUNT (*) AS NrClienti FROM CLIENŢI Prezenţa asteriscului ca argument al funcţiei COUNT are ca efect numărarea liniilor tabelei CLIENŢI Rezultatul este prezentat în figura NRCLIENTI Figura Câţi clienţi are firma ? Folosind concatenarea, se poate obţine un rezultat ceva mai elegant Spre exemplu, în Oracle, prin interogarea următoare se obţine rezultatul din figura (la concatenare nu este necesară conversia operanzilor în şiruri de caractere): SELECT 'Firma are '||COUNT (*)!!' clienţi' AS Rezultat FROM CLIENŢI REZULTAT Firma are clienţi Figura Altă formă de prezentare (în Oracle) a rezultatului funcţiei COUNT Pentru obţinerea aceluiaşi rezultat în VFP fraza se scrie sub forma: SELECT 'Firma are '+STR(COUNT(*), )+' clienţi' AS Rezultat FROM CLIENŢI iar în DB , în afara operatorului de concatenare CONCAT, este necesară conversia rezultatului funcţiei COUNT, care este INTEGER, în şir de caractere (CHAR): SELECT 'Firma are ' CONCAT CAST (COUNT (*) AS CHAR( )) CONCAT ' clienţi' AS Rezultat FROM CLIENŢI Tabela CLIENŢI are cheie primară atributul CodCl, care nu poate avea valori nule; de aceea, la fel de corectă este şi soluţia: SELECT COUNT (CodCl) AS NrClienti FROM CLIENŢI Câte linii are produsul cartezian al tabelelor FACTURI şi LINIIFACT? SELECT COUNT(*) FROM FACTURI, LINIIFACT Acum am aflat şi eu: Pentru câţi clienţi se cunoaşte adresa? SELECT COUNT (Adresa) AS NrClienti FROM CLIENŢI Rezultatul, , putea fi obţinut şi ceva mai complicat, folosind în clauza WHERE operatorul IS NULL, pe care- tot amânăm pentru capitolul următor Câte facturi au fost emise pe august ? SELECT COUNT(NrFact) AS NrFacturi FROM FACTURI WHERE DataFact = ' / / ' Câte facturi au fost emise clienţilor din judeţul Vaslui? SELECT COUNT(NrFact) AS NrFacturi FROM FACTURI F, CLIENŢI C, LOCALITATI L, JUDEŢE J WHERE F CodCl = C CodCl AND C CodPost=L CodPost AND L Jud = J Jud AND Judet='Vaslui' Nu ne mai ostenim să redactăm şi forma interogării cu INNER JOIN Rămâne ca temă pentru acasă, oricare ar fi ea în câte localităţi se află clienţii firmei? Tabela LOCALITĂŢI conţine şi oraşe/comune în care nu se află, momentan, nici un client De aceea, în locul soluţiei: SELECT COUNT(CodPost) AS NrLocalit FROM LOCALITATI pare mai înţe]epLsIL folosim varianta: SELECT COUNT(CodPost) AS NrLocalit ) FROM CLIENŢI Necazul e că rezultatul obţinut, , este incorect, deoarece funcţia COUNT numără toate valorile nenule Există însă o clauză prin care o valoare să se ia în calcul o singură dată: DISTINCT Rezultatul corect ( ) presupune varianta: SELECT COUNT(DISTINCT CodPost) AS NrLocalit FROM CLIENŢI Funcţia SUM SUM este una dintre cele mai utilizate funcţii în aplicaţiile economice, deoarece datele fmanciar-contabile şi cele ale evidenţei tehnico-operative sunt preponderent cantitative Probabil că prea multe explicaţii teoretice despre modul în care operează această funcţie sunt inutile, aşa încât vom trece în revistă câteva exemple Care este valoarea fără TVA a facturii ? SELECT SUM(Cantitate * PretUnit) AS ValFaraTVA FROM LINIIFACT WHERE NrFact =  Rezultatul arată ca în figura VALFARATVA Figura Valoarea fără TVA a facturii Care este valoarea fără TVA a facturilor emise pe august ? SELECT SUM(Cantitate * PretUnit) AS ValFaraTVA aug FROM LINIIFACT LF, FACTURI F WHERE LF NrFact = F NrFact AND DataFact = ' / / ' VALFARATVAJ AU Figura Valoarea fără TVA a facturilor emise pe august Care sunt cele trei valori: fără TVA, TVA şi totală ale facturii ? SELECT SUM(Cantitate * PretUnit) AS ValFaraTVA, SUM(Cantitate * PretUnit * ProcTVA) AS TVA, SUM(Cantitate * PretUnit + Cantitate * PretUnit * ProcTVA) AS ValTotala FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr = p CodPr AND NrFact = In condiţiile actuale, în care procentul TVA este unic - %, este corectă şi varianta: SELECT SUM(Cantitate * PretUnit) AS ValFaraTVA, SUM(Cantitate * PretUnit * ) AS TVA, SUM(Cantitate * PretUnit + Cantitate * PretUnit * ) AS ValTotala FROM LINIIFACT WHERE NrFact = Soluţia propusă este una atemporală, altfel spus, a-guvernamentală şi a-relaxare fiscală O vizualizare mai elegantă a rezultatului poate fi realizată în Oracle utilizând interogarea următoare, rezultatul fiind prezentat în figura (analog se pot croi şi variantele în DB şi VFP): SELECT 'Pentru factura , valoarea fara TVA este ' i | SUM(Cantitate * PretUnit)|| ', TVA este '||SUM(Cantitate * PretUnit * ProcTVA)|| ', iar valoarea totala este '|| SUM(Cantitate * PretUnit + Cantitate * PretUnit * ProcTVA) AS Rezultat FROM LINIIFACT, PRODUSE WHERE LINIIFACT CodPr=PRODUSE CodPr AND NrFact =  Dacă se doreşte afişarea pe verticală, sub formă tabelară, a celor trei valori, se pot folosi şabloane (ce diferă de la SGBD la SGBD) împreună cu operatorul reuniune, astfel încât rezultatul va arăta ca în figura Am uitat să vă spun că soluţia e valabilă în sintaxa de mai jos tot pentru Oracle SELECT ' ' AS X,'Pentru factura ' AS TipValoare, '' AS Suma FROM dual UNION SELECT ' ','Valoarea fara TVA', TO CHAR(SUM(Cantitate * PretUnit),' ') FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr = P CodPr AND NrFact = UNION SELECT ' ','TVA', TO CHAR(SUM(Cantitate * PretUnit * ProcTVA) ') FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr = p CodPr AND NrFact = UNION SELECT ' ','Valoarea totala', TO CHAR(SUM(Cantitate*PretUnit*( +ProcTVA)),' ') FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr = p CodPr AND NrFact = X TIPVALOARE SUMA   Pentru factura    Valoarea fara TVA    TVA    Valoarea totala    Figura Cele trei valori ale facturii - afişare pe verticală Funcţia TO CHAR converteşte valoarea numerică obţinută prin funcţia SUM într-un şir de caractere; prin utilizarea şablonului, valorile vor fi aliniate la dreapta, pentru a fi mai uşor de comparat Dacă tot am avut ocazia, am folosit şi tabela DUAL, o tabelă utilă în Oracle atunci când se doreşte extragerea prin SELECT a unei constante Tabela DUAL are o singură linie şi o singură coloană, servindu-ne în acest caz pentru afişarea aşa-zisului antet: Pentru factura Nu întotdeauna rezultatul reflectă ordinea firească de procesare a liniilor Este motivul pentru care am introdus în interogare o coloană (X), cu un prim rol decorativ şi un al doilea legat de afişarea liniilor în ordinea care interesează La cât se situează cifra vânzărilor pe data de august ? SELECT ' aug ' AS Data, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND DataFact = ' / / ' DATA VINZARI j   aug '   Figura Vânzările zilei de august Care este valoarea vânzărilor pentru „ Client SRL "? SELECT 'Client SRL' AS Client, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F CodCl = C CodCl AND DenCl = 'Client SRL' CLIENT VINZARI  Client SRL    Figura Vânzările către Client SRL Care este valoarea medie a preţului (inclusiv TVA) la care a fost vândut „Produs ”? Nu, n-am trecut la funcţia AVG fară să vă fi anunţat din timp Soluţia se bazează pe raportul dintre suma valorilor şi cantitatea însumată pentru acest produs SELECT SUM(Cantitate*PretUnit*( +ProcTVA)) / SUM(Cantitate) AS PretUnitMediu FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND DenPr = 'Produs ' Care este situaţia încasării facturii ? Rezolvarea acestei probleme presupune afişarea, pentru factura , atât a valorii totale, obţinută din tabelele LINIIFACT şi PRODUSE, cât şi a valorii încasate, obţinută din INCASFACT Prin urmare, pare firesc să încercăm varianta: SELECT ' ' AS NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat, SUM(Transa) AS încasat FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact AND F NrFact = NRFACT FACTURAT ÎNCASAT     Figura Valorile facturată şi încasată ale facturii Rezultatul din figura arată că lucrurile ar fi în regulă Dar dacă înlocuim numărul facturii cu , fraza: SELECT ' ' AS NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat, SUM(Transa) AS încasat j Y V° FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact AND F NrFact = va genera rezultatul din figura NRFACT FACTURAT ÎNCASAT     Figura Valoarea facturată şi valoarea încasată (greşită !) pentru factura Valoarea încasată e complet anapoda, cam de trei ori mai mare decât cea facturată Care e explicaţia? Răspunsul e mai uşor de aflat dacă vizualizăm rezultatul unei interogări „ajutătoare” ce generează tabela pe care se aplică cele două funcţii SUM - figura SELECT DenPr, Cantitate, PretUnit, Cantitate * PretUnit * ( +ProcTVA) AS Facturat, Transa - FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact AND F NrFact = DENPR CANTITATE PRETUNIT FACTURAT TRANSA  Produs      Produs      Produs       Figura Rezultatul joncţiunii „componentelor” facturare şi încasare pentru factura întâmplarea face ca pentru această factură să existe o singură tranşă de încasare Tranşa de lei se repetă pentru fiecare linie a facturii Normal că funcţia SUM întoarce o valoare triplă faţă de cea reală Ce-i de făcut? Să încercăm un artificiu împărţim suma tranşelor încasate la numărul liniilor facturii: SELECT ' ' AS NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat, SUM(Transa)/COUNT(*) AS încasat FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact AND F NrFact = Merge! Sau, cel puţin, aşa arată figura NRFACT [SATURAT ÎNCASAT       Rămâne însă o sursă de crispare: ce se întâmplă cu facturile încasate în mai multe tranşe? Spre exemplu, factura are două linii şi e încasată în trei tranşe Dacă utilizăm interogarea „ajutătoare” (penultima), schimbând, bineînţeles, numărul facturii, echivalenta tabelei din figura se prezintă ca în figura DENPR CANTITATE PRETUNIT FACTURAT [TRANSA  Produs      Produs      Produs      Produs    :  Produs      Produs       Figura Valori repetate datorită mai multor tranşe de încasare - factura Există nu mai puţin de (tranşe de încasare - INCASFACT) * (linii în LINIIFACT) = linii Pe baza acestei observaţii ochiometrice, putem să încercăm o soluţie finală, împărţind valoarea facturată la numărul tranşelor de încasare şi valoarea încasată la numărul de linii ale facturii respective: SELECT ' ' AS NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT I Codlnc) AS Facturat, SUM(Transa)/ COUNT(DISTINCT(LF Linie)) AS încasat FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact AND F NrFact = NRFACT FACTURAT ÎNCASAT     Figura Valorile (corecte) facturată şi încasată - factura Rezultatul din figura ne îndreptăţeşte să sperăm că soluţia e bună Şi, într-adevăr, este funcţională, dar numai pentru facturile care au cel puţin o tranşă de încasare! Pentru cealaltă categorie avem nevoie de cunoştinţe ceva mai avansate (joncţiune externă) Visual FoxPro nu ne dă, însă, pace La execuţia acestei variante apare usturătorul mesaj de eroare: SQL: DISTINCT is invalid, eroare ce are numărul şi se datorează, după cum scrie „la documentaţie”, faptului că se poate utiliza un singur DISTINCT pe nivel Vom putea remedia situaţia folosind funcţia MAX Funcţia A VG Ultimele exemple discutate se doresc o trecere lină la prezentul operator care, după cum îi spune şi numele (în engleză), calculează media aritmetică a unei coloane într-o tabelă oarecare, prin divizarea sumei valorilor coloanei respective la numărul de valori nenule ale acesteia Care este valoarea (fară TVA) medie a produselor vândute în factura ? Rezultatul din figura se obţine prin interogarea: SELECT 'Val medie (fara TVA) a prod din fact ' AS Explicaţii,AVG(Cantitate * PretUnit) AS ValMedie FROM LINIIFACT WHERE NrFact = EXPLICAŢII VALMEDIE  Val medie (fara TVA) a prod din fact    Figura Valoarea medie a produselor din factura Care este media valorilor (cu TVA) la care a fost vândut,, Produs ”? SELECT 'Val medie a vinzarilor prod Produs ' AS Explicaţii, ROUND(AVG(Cantitate*PretUnit*( +ProcTVA)), ) ValTotMedie FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND DenPr = 'Produs ' Adesea, prin aplicarea funcţiei AVG sau prin formularea unor expresii ce conţin rapoarte între atribute/constante, se obţin rezultate cu numeroase zecimale In cazul de faţă, pentru preîntâmpinarea acestui disconfort vizual şi intelectual, a fost preferată funcţia ROUND, ce rotunjeşte media la două zecimale - vezi figura EXPLICAŢII VALTOTMEDIE  Val medie a vinzarilor prod Produs    Figura Funcţia AVG combinată cu ROUND Funcţiile MAX şi MIN Deosebit de utile în diverse tipuri de analiză, cele două funcţii determină valoarea maximă, respectiv minimă, pentru o coloană (atribut) Se pot folosi şi pentru atribute de tip şir de caractere, caz în care elementul de comparaţie este codul ASCII al caracterelor Care este localitatea cu ultima denumire, în ordine alfabetică? SELECT MAX(Loc) AS UltimaLoc FROM LOCALITATI ULTIMALOC Vaslui Figura Ultima localitate (alfabetic) din baza de date Care este primul client şi ultimul client (în ordinea numelui) din judeţul Iaşi? SELECT MIN(DenCl) AS Primul Client, MAX(DenCl) AS Ultimul Client FROM CLIENŢI C, LOCALITATI L, JUDEŢE J WHERE C CodPost = L CodPost AND L Jud = J Jud AND Judeţ = 'lasi' PRIMUl CLIENT   Client SRL Client   Figura Primul şi ultimul client din judeţul laşi Care este cel mai mare preţ unitar (fară TVA) la care a fost vândut „ Produs ”? SELECT MAX(PretUnit) FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr = P CodPr AND DenPr = 'Produs ' Din păcate, dacă dorim să aflăm şi în ce factură produsul are preţul unitar maxim, soluţia: SELECT MAX(PretUnit), NrFact FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr = P CodPr AND DenPr = 'Produs ' nu funcţionează! Până la subconsultările din capitolul viitor încercăm o soluţie gen „cârpeală”, con- catenând preţul cu numărul facturii Varianta următoare este valabilă pentru Oracle: SELECT 'Pret maxim='||MAX(TO CHAR(LF PretUnit,' ')|| ', apare in fact '|INrFact) AS Produşi FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr = P CodPr AND DenPr = 'Produs ' Interogarea este operaţională, cel puţin dacă ne luăm după rezultatul din figura , aşa că n-are de ce să ne fie jenă de improvizaţie Rezultatul este incomplet însă, atunci când preţul maxim apare în două sau mai multe facturi, deoarece interogarea de mai sus extrage numai una dintre facturi (cea cu numărul cel mai mare) PR DUS Pret maxim= , apare in fact Figura Preţul maxim pentru „Produs ” şi factura în care apare acest preţ Care este cel mai mare şi cel mai mic preţ unitar (fără TVA) la care a fost vândut „ Produs ”? Dacă în ultimele exemple am pedalat pe Oracle, iată acum două variante DB şi VFP DB : SELECT MAX( 'Pret maxim=' CONCAT CAST (PretUnit AS CHAR( )) CONCAT ', factura' CONCAT CAST (NrFact AS CHAR(IO))) AS Max Pret Produs , MIN( 'Pret minim=' CONCAT CAST (PretUnit AS CHAR( )) CONCAT ', factura' CONCAT CAST (NrFact AS CHAR(IO))) AS Min Pret Produs FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr = P CodPr AND DenPr = 'Produs ' VFP: SELECT MAXf'Pret maxim='+STR(PretUnit, )+', ; factura'+STR(NrFact, )) AS Max Pret Produs , ; MIN('Pret minim='+STR(PretUnit, )+; factura'+STR(NrFact, )) AS Min Pret Produs ; FROM LINIIFACT LF, PRODUSE P ; WHERE LF CodPr = P CodPr AND DenPr = 'Produs ' Care sunt cele mai mari două preţuri unitare (fără TVA) la care a fost vândut „ Produs ’’? După cum vedeţi, o căutăm cu lumânarea Iată soluţia Oracle: SELECT 'Produs : || MAX('Primul PU: '||TO CHAR(LF PretUnit,' ')|| ', al doilea PU: '||TO CHAR(LF PretUnit,' ')I| ' - factura primului:'||LF NrFact|| ', factura-al doilea:'||LF Nrfact) AS "Cele mai mari doua PretUnit" FROM LINIIFACT LF , LINIIFACT LF , PRODUSE P WHERE LF CodPr = P CodPr AND DenPr = 'Produs ’ AND LF CodPr = LF CodPr AND LF PretUnit > LF PretUnit Pe acelaşi calapod se redactează soluţiile DB şi VFP, a căror sintaxă depinde regulile fiecărui SGBD de conversie între diferite tipuri de date Care este situaţia încasării facturii ? A sosit momentul rezolvării problemei VFP care nu permite mai mulţi DISTINCTi pe un nivel de interogare Soluţia este foarte simplă în loc să numărăm valorile distincte ale atributului Linie în LINIIFACT, determinăm maximul acestui atribut pentru factura luată în considerare Obţinem astfel varianta VFP, care, fireşte, funcţionează şi în celelalte două SGBD: SELECT ' ' AS NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT I Codlnc) AS Facturat, SUM(Transa) / MAX(LF Linie) AS încasat FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact AND F NrFact = Gruparea tuplurilor GROUP BY şi HAVING Clauza GROUP BY formează grupe (grupuri) de tupluri ale unei relaţii, pe baza valorilor comune ale unui atribut în frazele SELECT formulate până în acest paragraf, prin intermediul WHERE au fost selectate tupluri ale tabelei Prin asocierea unei clauze HAVING !a GROUP BY este posibilă selectarea anumitor grupuri de tupluri ce îndeplinesc un criteriu, valabil numai la nivel de grup (nu şi la nivel de linie) Clauza GROUP BY Rezultatul unei fraze SELECT ce conţine această clauză se obţine prin regruparea tuturor liniilor din tabelele enumerate în FROM, extrăgându-se câte o apariţie pentru fiecare valoare distinctă a coloanei/grupului de coloane Formatul general este: SELECT coloană , coloană , coloană m FROM tabelă GROUP BY coloană-de-regrupare Care este valoarea fară TVA a fiecărei facturi emise? SELECT NrFact, SUM(Cantitate*PretUnit) as ValFaraTVA FROM LINIIFACT GROUP BY NrFact Rezultatul se obţine prin următoarea succesiune de operaţii: Se ordonează liniile tabelei LINIIFACT după atributul de grupare NrFact Se constituie un grup pentru fiecare valoare distinctă a NrFact Se execută funcţia SUM (Cantitate*PretUnit) în cadrul fiecărui grup Se obţine rezultatul al cărui număr de linii coincide cu valorile distincte ale NrFact, Schema simplificată de execuţie a interogării este prezentată în figura Care este valoarea totală a vânzărilor pentru fiecare zi în care s-au emis facturi? SELECT DataFact, SUM(Cantitate * PretUnit * ( +ProcTVÂ)) AS ValTotala FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact GROUP BY DataFact  Figura S Schema de execuţie a clauzei GROUP BY Rezultatul este cel din figura DATAFACT VALTOTALA   -AUG-   AUG- AUG-    -AUG-    -AUG-    Figura Vânzările zilnice Care sunt numărul de facturi şi valoarea vânzărilor pentru fiecare client? SELECT DenCl, COUNT(DISTINCT F NrFact) AS NrFacturilor, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS ValTotala FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F CodCl = C CodCl GROUP BY DenCl Analizând rezultatul din figura şi comparându- cu tabela FACTURI, se observă că al cincilea client ar trebui să aibă două facturi, nu una Această anomalie aparentă se datorează faptului că factura nu are nici o linie corespondentă în LINIIFACT, astfel încât această factură „cade” la joncţiune DENCL NRFACTURILOR VALTOTALA  Clienţi SRL  Client SA  Client SRL   Client   Client SRL   Client SA   Client SRL   Figura Numărul facturilor şi valoarea vânzărilor pe clienţi Care este restul de încasat al fiecărei facturi? Aşa cum reiese din figura , soluţia următoare oferă un rezultat incomplet Lipsesc facturile care nu au nici o tranşă de încasare Pentru rezolvarea cazului, avem nevoie de clauza HAVING, dar şi de joncţiunea externă, după cum vom vedea în capitolul următor SELECT F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT I Codlnc) AS Facturat, SUM(Transa) / MAX(LF Linie) AS încasat FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact GROUP BY F NrFact NRFACT FACTURAT ÎNCASAT                     Figura Valorile facturată şi încasată pentru fiecare factură - rezultat incomplet Care sunt vânzările, cantitativ şi valoric, pentru fiecare produs? SELECT DenPr, SUM(Cantitate) AS Cantitativ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Valoric FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact GROUP BY DenPr Rezultatul - figura DENPR CANTITATIV VALORIC  Produs    Produs    Produs    Produs    Produs    Figura Vânzările cantitative şi valorice pe produse O informaţie esenţială care lipseşte din figura este unitatea de măsură, fară de care nu putem î siguri dacă totalul cantitativ se referă la cutii, sticle, pachete, baxuri etc Din păcate, varianta: SELECT DenPr, UM, SUM(Cantitate) AS Cantitativ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Valoric FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact GROUP BY DenPr nu funcţionează, deoarece UM apare separat de atributul de grupare, nefiind inclus în funcţia/ funcţiile care se execută la nivelul grupului Există însă un remediu simplu: includerea în clauza de grupare şi a atributului UM Altminteri, gruparea este identică, deoarece DenPr este cheie candidată a tabelei PRODUSE, lucru observabil în figura SELECT DenPr, UM, SUM(Cantitate) AS Cantitativ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Valoric FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact GROUP BY DenPr, UM DENPR UM CANTITATIV VALORIC  Produs buc    Produs kci   Produs Produs Kg l    Produs S buc     Figura includerea în rezultat a unităţii de măsură Care este situaţia vânzărilor pe clienţi şi zile? ( Interesează valoarea facturilor emise pe clienţi şi, pentru fiecare client, cuantumul zilnic al acestora Este momentul să folosim o veritabilă grupare după două atribute (spre deosebire de exemplul precendent, când gruparea celor două atribute a fost mai mult de nevoie, decât de voie) SELECT DenCl AS DenumireClient, DataFact AS Data, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact AND F CodCl = C CodCl GROUP BY DenCl, DataFact DENUMIRECLIENT DATA VINZARI  Client SRL  -AUG-   Client SRL  -AUG-   Client SRL  -AUG-   Client SRL  -AUG-   Client SRL  -AUG-   Client SA  -AUG-   Client SRL  -AUG-   Client  -AUG-   Client SRL  -AUG-   Client SA  -AUG-   Client SRL  -AUG-    Figura Vânzările zilnice pentru fiecare client Care este situaţia vânzărilor fiecărui produs pe fiecare regiune? SELECT DenPr AS Produs, Regiune, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C, LOCALITATI L, JUDEŢE J WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact AND F CodCl=C CodCl AND C CodPost=L CodPost AND L Jud=J Jud GROUP BY DenPr, Regiune PRODUS REGIUNE VINZARI  Produs Moldova   Produs Banat   Produs Moldova   Produs Banat   Produs Produs Produs Moldova Moldova Moldova    Figura Vânzările pe regiuni ale fiecărui produs Să se obţină situaţia vânzărilor pe produse, regiuni şi zile Exemplul de faţă este o bună ocazie de a folosi gruparea după trei atribute şi, implicit, o analiză a vânzărilor pe cele axe tradiţionale: sortimentală, teritorială şi calendaristică SELECT DenPr AS Produs, Regiune, DataFact AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C, LOCALITATI L, JUDEŢE J WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact AND F CodCl=C CodCl AND C CodPost=L CodPost AND L Jud=J Jud GROUP BY DenPr, Regiune, DataFact Rezultatul e ceva mai impresionant - vezi figura Fără îndoială, interogările de mai sus constituie un ajutor esenţial în analiza vânzărilor oricărei firme (chiar şi de stat) Ceea ce lipseşte este un ingredient important al oricărui raport de acest gen - subtotalul Vom recurge, aşa cum v-aţi obişnuit, la improvizaţii Reluăm una dintre problemele anterioare, modificându-i uşor enunţul: Să se obţină situaţia vânzărilor pe clienţi şi zile, afişându-se câte un subtotal la nivel de client şi un total general Ideea improvizaţiei este să „alipim’, pentru fiecare client, după vânzările zilnice, câte o linie care să conţină subtotalul Iată varianta Oracle şi rezultatul din figura PRODUS REGIUNE Figura Gruparea vânzărilor pe produse, regiuni şi zile SELECT DenCl AS DenumireClient, TO CHAR(DataFact,'DD-MM-YYYY') AS Data, TO CHAR(SUM(Cantitate * PretUnit * ( +ProcTVA)), ' ') AS Vinzari FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact AND F CodCl=C CodCl GROUP BY DenCl, DataFact UNION SELECT DenCl II' - Subtotal' , NULL, TO CHAR(SUM(Cantitate * PretUnit * ( +ProcTVA)), ' ') FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact AND F CodCl=C CodCl GROUP BY DenCl UNION SELECT CHR( )II'TOTAL GENERAL' , NULL, TO CHAR(SUM(Cantitate * PretUnit * ( +ProcTVA)), ' ') FROM LINIIFACT LF, PRODUSE P WHERE P CodPr = LF CodPr Cu modificările de rigoare, soluţia este asemănătoare şi în DB în VFP trebuie ţinut cont că dimensiunea unei coloane de tip şir de caractere depinde în rezultat de numărul de caractere de pe prima linie a rezultatului Astfel încât pentru denumirea clientului mai trebuie asigurat spaţiu pentru cuvântul Subtotal, utilizându-se în acest scop funcţia PADR () DENUMIRECLIENT DATA VINZARI  Client SRL  - -   Client SRL  - -   Client SRL  - -   Client SRL  - -  Client SRL  - -   Client SRL - Subtotal    Client SA  - -   Client SA - Subtotal    Client SRL  - -   Client SRL - Subtotal    Client  - -   Client - Subtotal    Client SRL  - -   Client SRL - Subtotal |   Client SA  - -   Client SA - Subtotal    Client SRL  - -   Client SRL - Subtotal   yTOTAL GENEI    Figura Vânzările grupate pe clienţi şi zile, cu subtotaluri şi total general - soluţie Oracle SELECT PADR(ALLT(DenCl), ) AS DenumireClient, ; DataFact, ; SUM ("Cantitate * PretUnit * ( + ProcTVA)) AS Vinzari ; FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C ; WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact ; AND F CodCI =C CodC l ; GROUP BY DenCl, DataFact ; UNION ; SELECT PADR(ALLT(DenCl)+'-Subtotal', ), ; {//},; SUM(Cantitate * PretUnit * ( +ProcTVA)) ; FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C ; WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact ; AND F CodCl=C CodCI ; GROUP BY DenCl ; UNION ; SELECT CHR( )+'TOTAL GENERAL' , ; { / / }, ; SUM(Cantitate * PretUnit * ( +ProcTVA)) ; FROM LINIIFACT LF, PRODUSE P ; WHERE P CodPr = LF CodPr Rezultatul interogării este afişat în figura -lai * Denumiieclient Datafact Vinzari  ti  Client SRL  / /     Client SRL  / /     Client SRL  / /    " Client SRL  / /     Client SRL  / /     Client SRL-Subtotal / /     Client SA  / /     Client SA-Subtotal / /  ;    Client SRL  / /  !    Client SRL-Subtotal / /  !    Client  / /  !    Client -Subtotal / /  !    Client SRL  / /  !    Client SRL-Subtotal / /     Client G SA  / /  ;    Client SA-Subtotal / /  ;    sPient SRL  / /  !   ! Client SRL-Subtotal / /  !    jifOTÂL GENERAL l LL  ;   Figura Vânzări pe clienţi şi zile, cu subtotaluri şi total general - soluţie VFP Care este cea mai mare valoare a unei facturi? Această interogare este prea pretenţioasă pentru nivelul de SQL la care ne situăm în prezent Cu toate acestea, Oracle prezintă o facilitate grozavă prin care putem redacta un răspuns: includerea unei funcţii în alta (rezultatul este prezentat în figura ) Din păcate, nici DB , nici VFP nu „suportă” această facilitate: SELECT MAX(SUM(Cantitate * PretUnit * ( +ProcTVA))) AS VaxMaxFact FROM LINIIFACT LF, PRODUSE P WHERE P CodPr = LF CodPr GROUP BY NrFact VAXMAXFACT Figura Valoarea maximă a unei facturi Clauza HA VING Cea mai simplă definiţie: clauza HAVING este WHERE-ul ce operează la nivel de grupuri Dacă WHERE acţionează la nivel de tuplu, selectând acele linii care îndeplinesc o condiţie specificată, HAVING permite specificarea unor condiţii de selecţie care se aplică grupurilor de linii create prin clauza GROUP BY Din rezultat sunt eliminate toate grupurile care nu satisfac condiţia specificată Formatul general este: SELECT coloană , coloană , , coloană m FROM tabelă GROUP BY coloană-de-regrupare HAVING caracteristică-de-grup Care sunt zilele în care s-au întocmit cel puţin trei facturi? SELECT DataFact, COUNT(*) AS Nr Facturi FROM FACTURI GROUP BY DataFact HAVING COUNT(*) >= DATAFACT NR^FACTURI   - -    - -    Figura Zilele în care s-au întocmit trei sau mai multe facturi Rezultatul este cel din figura Logica operaţiunilor este prezentată în figura Pas Ordonare dupa DataFact NrFacs DataFact CodCI Obs      - -        - -  Probleme cu transportul      - -   n\\ Pas Grupare    - -   - \\\ DataFact COUNTn    - -     - -     - -  Preţul propus iniţial a fost modificat -  - -     - -    *  - -     - -    -*  - -     - -     - -     - -         - -        - -       Figura Logica execuţiei clauzelor GROUP BY şi HAVING Care sunt clienţii pentru care vânzările depăşesc milioane (lei)? SELECT DenCl AS Client, SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE P CodPr = LF CodPr AND LF NrFact AND F CodCl=C CodCI GROUP BY DenCl HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) > CLIENT VINZARI  Client SRL   Client SRL   Client   Client SA    în ce zile s-au emis mai multe facturi decât pe august ? Cu volumul de cunoştinţe pe care- avem, putem să redactăm o variantă elegantă, valabilă în SQL- , DB şi Oracle Soluţia următoare Oracle obţine rezultatul corect, după cum se observă în figura SELECT FI DataFact AS Zii, COUNT(DISTINCT Fl NrFact) AS Nr Facturilorl, F DataFact AS Zi , COUNT(DISTINCT F NrFact) AS Nr Facturilor FROM FACTURI FI, FACTURI F WHERE F DataFact = TO DATE(' / / ', 'DD/MM/YYYY') GROUP BY FI DataFact, F DataFact HAVING COUNT(DISTINCT Fl NrFact) > COUNT(DISTINCT F NrFact)  Figura Zilele în care s-au emis mai multe facturi decât pe august Să zăbovim asupra logicii acestei interogări Mai întâi se efectuează produsul cartezian pentru două instanţe (FI şi F ) ale tabelei FACTURI, eliminându-se pentru F liniile în care data este alta decât august Rezultatul produsului cartezian urmat de selecţie (nu este vorba nicidecum de joncţiune): SELECT * FROM FACTURI FI, FACTURI F WHERE F DataFact = TO DATE(' / / ', 'DD/MM/YYYY') ORDER BY FI DataFact, F DataFact este cel din figura NRFACT ]DATAFACT ICODCl oes NRFACT (DATAFACT |CODCL |OBS    -AUG-   -AUG-      -AUG- Probleme cu transportul   -AUG-      -AUG- (  -AUG-      -AUG-   -AUG-      -AUG-   -AUG-  : Preţul propus iniţial a fost modificat    -AUG-   -AUG-  Preţul propus iniţial a fost modificat    -AUG- Probleme cu transportul   -AUG-  Preţul propus iniţial a fost modificat    -AUG-   -AUG-  Preţul propus iniţial a fost modificat    -AUG-   -AUG-      -AUG- Preţul propus iniţial a fost modificat   -AUG-  Preţul propus iniţial a fost modificat    -AUG-   -AUG-  Preţul propus iniţial a fost modificat    -AUG- Preţul propus iniţial a fost modificat   -AUG-      -AUG-    -AUG-      -AUG-    -AUG-  Preţul propus iniţial a fost modificat    -AUG-    -AUG-      -AUG-    -AUG-  Preţul propus iniţial a fost modificat    -AUG-   -AUG-      -AUG-   -AUG-      -AUG-   -AUG-  : Preţul propus iniţial a fost modificat    -AUG-   -AUG-  Preţul propus iniţial a fost modificat    -AUG-   -AUG-  Preţul propus iniţial a fost modificat    -AUG-   -AUG-  Preţul propus iniţial a fost modificat    -AUG-   -AUG-  |    -AUG-   -AUG-    în pasul următor se constituie grupuri pentru fiecare combinaţie de valori (FI DataFact, F DataFact) F DataFact are aceeaşi valoare, / / , prin urmare grupurile se constituie în funcţie de Fl DataFact Primul grup acoperă primele linii, în care FI DataFact este / / , al doilea linii ş a m d Pentru ca funcţia COUNT să calculeze corect numărul facturilor dintr-o zi, este necesară clauza DISTINCT Care sunt judeţele în care volumul vânzărilor este superior celui al judeţului Neamţ? Ideea rezolvării este preluată din exemplul anterior Problema cea mai dificilă ţine de luarea în calcul o singură dată a fiecărei linii dintr-o factură Cum, la un moment dat, pot apărea în două facturi diferite linii în care cantităţile şi preţurile unitare să fie identice, am introdus, ca artificiu, împărţirea numărului facturii la el însuşi şi a numărului de linie la el însuşi Varianta următoare funcţionează în Oracle : SELECT Jl Judeţ, J Judeţ, SUM(DISTINCT (LF NrFact/LFl NrFact) * (LF Linie/LFl Linie) * LF Cantitate * LF PretUnit * ( + PI ProcTVA)) AS Vinzaril, SUM(DISTINCT (LF NrFact/LF NrFact) * (LF Linie / LF Linie) * LF Cantitate * LF PretUnit * ( + P ProcTVA)) AS Vinzari FROM JUDEŢE Jl, LOCALITATI LI, CLIENŢI CI, FACTURI FI, LINIIFACT LF , PRODUSE PI, JUDEŢE J , LOCALITATI L , CLIENŢI C , FACTURI F , LINIIFACT LF , PRODUSE P WHERE Jl Jud=Ll Jud AND LI CodPost=Cl CodPost AND CI CodCl=Fl CodCl AND FI NrFact=LFl NrFact AND LFl CodPr=Pl CodPr AND Jl Judet='Neamţ' AND J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY Jl Judeţ, J Judeţ HAVING SUM(DISTINCT (LF NrFact/LF NrFact)* (LF Linie/LFl Linie) * LF Cantitate * LF PretUnit * ( + PI ProcTVA)) = ' - - ' MARCA NUMEPREN DATANASTIcOMPART MARCASEF SALTARIFAR   ANGAJAŢI -JUL- DIRECŢIUNE    ANGAJAT -AUG- MARKETING    ANGAJAT  -APR- FINANCIAR    ANGAJAT  -NOV- FINANCIAR    ANGAJAT  -DEC- MARKETING    Figura Persoane născute înainte de ianuarie MARCA NUMEPREN DATANAST COMPART MARCASEF SALTARIFAR   ANGAJAT  -OCT- FINANCIAR     ANGAJAT  -FEB- MARKETING     ANGAJAT -JAN- RESURSE UMANE     Se observă un lucru curios: dacă reunim mulţimea angajaţilor născuţi înainte de data fixată cu mulţimea celor născuţi după această dată nu obţinem relaţia iniţială PERSONAL (figura ) SELECT * FROM PERSONAL WHERE DataNast = ' - - ' MARCA NUMEPREN DATANAST COMPART MARCASEF SALTARIFAR   ANGAJAT  -JUL- DIRECŢIUNE     ANGAJAT  -OCT- FINANCIAR     ANGAJAT  -AUG- MARKETING     ANGAJAT  -APR- S FINANCIAR     ANGAJAT  -NOV- FINANCIAR     ANGAJAT  -DEC- MARKETING     ANGAJAT  -FEB- MARKETING     ANGAJAT  -JAN- RESURSE UMANE     Figura Reuniunea persoanelor născute înainte de ianuarie cu persoanele născute după această dată Din tabela obţinută în figura lipsesc angajaţii care nu au precizată data naşterii, altfel spus, persoanele „fără vârstă” (precum maestrul Gică Petrescu) Pentru recompunerea tabelei PERSONAL , în reuniune mai trebuie adăugate şi liniile pentru care DataNast IS NULL: SELECT * FROM PERSONAL WHERE DataNast = ' - - ' UNION SELECT * FROM PERSONAL WHERE DataNast IS NULL ‘ ORDER BY Marca Acest exemplu este grăitor în privinţa logicii trivalente a modelului relaţional în ceea ce priveşte valorile nule în continuare, interesează un alt aspect al NULL-ităţilor: modul de evaluare a expresiilor în care unul sau mai mulţi operanzi au valori nule Care este totalul sporurilor fiecărui angajat pe luna iulie ? Soluţia pare a fi de forma: SELECT SPORURI Marca, NumePren, Compart, SporVechime + SporNoapte + SporCD + AlteSpor AS TotalSporuri KP  FROM PERSONAL , SPORURI WHERE PERSONAL Marca=SPORURI Marca AND An = AND Luna= Din păcate, rezultatul este incorect - vezi figura - deoarece, din prezentarea conţinutului tabelei SPORURI (figura ) reiese că, pe luna iulie , ANGAJAT are calculat spor de vechime ( lei), iar ANGAJAT are, pe aceeaşi lună, şi spor de vechime ( lei), şi de noapte ( lei), şi alte sporuri ( lei), iar aceste sporuri nu au fost luate în calcul la însumare MARCA NUMEPREN COMPART TOTALSPORURI   ANGAJAT DIRECŢIUNE    ANGAJAT FINANCIAR    ANGAJAT MARKETING    ANGAJAT FINANCIAR   S ANGAJAT FINANCIAR    ANGAJAT FINANCIAR    ANGAJAT FINANCIAR    ANGAJAT MARKETING    ANGAJAT MARKETING    ANGAJAT RESURSE UMANE    Figura Rezultatul unei expresii în care cel puţin un operand este NULL Explicaţia este simplă: dacă, într-o expresie, unul dintre operanzi este NULL, atunci rezultatul evaluării întregii expresii este NULL Fac excepţie funcţiile statistice Dacă, spre exemplu, vrem să calculăm: Totalul sporurilor de noapte acordate pentru luna iulie , fraza: SELECT SUM(SporNoapte) AS Total SporuriNoapte Luna FROM SPORURI WHERE An = AND Luna= calculează corect rezultatul: lei Revenim la cazul cu probleme Pentru a asigura corectitudinea totalului, ar trebui ca în expresie orice valoare nulă să fie considerată zero Lucru realizabil, deoarece SQL- este „prevăzut” cu o funcţie în acest sens - COALESCE: SELECT SPORURI Marca, NumePren, Compart, COALESCE(SporVechime, ) + COALESCE (SporNoapte, ) + COALESCE (SporCD, ) + COALESCE (AlteSpor, ) AS TotalSporuri FROM PERSONAL , SPORURI WHERE PERSONAL Marca=SPORURI Marca AND An = AND Luna= MARCA NUMEPREN COMPART TOTALSPORURI   ANGAJAT DIRECŢIUNE    ANGAJAT FINANCIAR    ANGAJAT MARKETING    ANGAJAT FINANCIAR    ANGAJAT FINANCIAR    ANGAJAT FINANCIAR    ANGAJAT FINANCIAR    ANGAJAT MARKETING    ANGAJAT MARKETING    ANGAJAT RESURSE UMANE    Figura Conversia valorilor nule în zero şi evaluarea corectă a expresiei în DB , de obicei, funcţiei COALESCE îi este preferată o alta ce produce rezultate identice - VALUE Prin urmare, ultima soluţie se poate rescrie astfel: SELECT SPORURI Marca, NumePren, Compart, VALUE (SporVechime, ) + VALUE(SporNoapte, ) + VALUE (SporCD, ) + VALUE (AlteSpor, ) AS TotalSporuri FROM PERSONAL , SPORURI WHERE PERSONAL Marca=SPORURI Marca AND An = AND Luna= Oracle şi Visual FoxPro pun la dispoziţie o altă funcţie ce acţionează după aceeaşi logică - NVL (de la NullVaLue), astfel încât varianta comună pentru interogarea anterioară este: SELECT SPORURI Marca, NumePren, Compart, NVL(SporVechime, ) + NVL(SporNoapte, ) + NVL(SporCD, ) + NVL(AlteSpor, ) AS TotalSporuri FROM PERSONAL , SPORURI WHERE PERSONAL Marca=SPORURI Marca AND An = AND Luna= Este important de reţinut că funcţiile VALUE, COALESCE, NVL nu se aplică la nivel de expresie, ci fiecărui operand susceptibil de nulitate De asemenea, un alt element interesant legat de valorile nule ţine de conversia în sens invers, dintr-o valoare oarecare, în NULL Să se determine totalul sporurilor de noapte pentru luna iulie , dar, în rezultat, să nu fie luate în calcul valoarea (valorile) lei Soluţia „clasică” este: SELECT SUM(SporVechime) FROM SPORURI WHERE An = AND Luna= AND SporVechime <> O variantă ceva mai elegantă se redactează prin utilizarea funcţiei NULLIF prezentă în SQL- care, în interogarea de mai jos, converteşte orice apariţie a valorii în NULL: SELECT SUM(NULLIF(SporVechime, )) FROM SPORURI WHERE An = AND Luna= în Oracle nu există funcţia NULLIF, dar în locul său se poate folosi REPLACE: SELECT SUM(REPLACE(SporVechime, ,NULL)) FROM SPORURI WHERE An = AND Luna= Visual FoxPro nu dispune de nici una dintre funcţiile de mai sus, dar, după cum vom vedea într-un viitor paragraf, conversia (substituirea) valorilor este posibilă prin IF-ul imediat (I IF-ul) Joncţiunea externă Standardul SQL- introduce operatorii necesari joncţiunii externe: LEFT OUTER JOIN pentru joncţiune externă la stânga, RIGHT OUTER JOIN pentru joncţiune externă la dreapta, FULL OUTER JOIN pentru joncţiune externă totală (în ambele direcţii) Dacă ne raportăm la exemplul teoretic din algebra realaţională (capitolul , figura ), atunci joncţiunile externe la stânga, la dreapta şi totală dintre relaţiile Rl şi R se transcriu în standardul SQL- astfel: Joncţiune externă la stânga SELECT * FROM Rl LEFT OUTER JOIN R ON Rl C=R C Joncţiune externă la dreapta SELECT * FROM Rl RIGHT OUTER JOIN R ON Rl C=R C Joncţiune externă totală SELECT * FROM Rl FULL OUTER JOIN R ON R C=R C Atât DB , cât şi Visual FoxPro au implementaţi aceşti operatori; însă, curios, nici până la versiunea Oracle nu a implementat OUTER JOIN-ul Totuşi, joncţiunea externă este realizabilă, dar ceva mai greoi, astfel: Joncţiune externă la stânga SELECT * FROM Rl, R WHERE Rl C = R C (+) Joncţiune externă la dreapta SELECT * FROM Rl, R WHERE Rl C (+) = R C Joncţiune externă totală Nu există nici o posibilitate directă de a joncţiona total două tabele Unica soluţie este reuniunea rezultatelor joncţiunii la stânga şi la dreapta: SELECT * FROM R , R WHERE Rl C (+) = R C UNION SELECT * FROM Rl, R WHERE Rl C = R C (+) Cele trei caractere, ( + ), care simbolizează joncţiunea externă sunt plasate în dreptul tabelei din dreapta LEFT OUTER JOIN-ului şi celei din stânga RIGHT OUTER JOIN-ului Un element (suplimentar) creator de confuzii îl constituie faptul că simbolul (cele trei caractere) este plasat diferenţiat, fie înaintea semnului =, în cazul joncţiunii externe la dreapta, fie imediat după atributul din dreapta semnului =, în cazul joncţiunii externe la stânga Următorul exemplu este desprins tot din algebra relaţională (exemplul ): Care sunt localităţile în care nu avem nici un client? SELECT * FROM LOCALITATI LEFT OUTER JOIN CLIENŢI ON LOCALITATI CodPost = CLIENŢI CodPost WHERE CLIENŢI CodPost IS NULL CODPOST |LOC JUD CODCL DENCL CODFISCAL ADRESA CODPOST TELEFON   Focşani VN   Suceava SV   Birlad VS  Figura Localităţile în care nu sunt clienţi Care este situaţia încasării facturii ? Revenim la un exemplu din capitolul anterior, de la funcţiile SUM şi MAX Spuneam, la momentul respectiv, că soluţia formulată este valabilă numai pentru facturile cu măcar o tranşă de încasare Beneficiind de avantajele joncţiunii externe, se poate redacta o soluţie ameliorată care va funcţiona în orice situaţie Pentru obţinerea valorii facturate trebuie împărţită suma totală la numărul de tranşe de încasări (repetarea se producea din cauza joncţiunii) Atunci când nu există nici o tranşă, împărţirea trebuie să se facă la ; astfel încât expresia valorii totale a facturii va fi: SUM (Cantitate PretUnit * ( + ProcTVA)) / COUNT (DISTINCT VALUE (I Codlnc, )) In schimb, totalul tranşelor încasate ( dacă nu există nici o tranşă) trebuie împărţit, pentru fiecare factură, la numărul de linii din factură De aici expresia: SUM (VALUE (Transa, )) / MAX (LF Linie) Soluţia SQL- şi DB : SELECT ' ' AS NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I CodInc,l)) AS Facturat, SUM(VALUE(Transa, ))/ MAX(LF Linie) AS încasat FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr = P CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact WHERE F NrFact = Aşa cum am văzut, DB permite folosirea, în locul VALUE, a funcţiei COALESCE Soluţia echivalentă Visual FoxPro: SELECT ' ' AS NrFact, SUM(Cantitate * PretUnit * ( + ProcTVA)) / ; COUNT(DISTINCT NVL(I Codlnc, )) AS Facturat, ; SUM(NVL(Transa, )) / MAX(LF Linie) AS încasat ; FROM LINIIFACT LF ; INNER JOIN PRODUSE P ON LF CodPr = P CodPr ; INNER JOIN FACTURI F ON LF NrFact = F NrFact ; LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact ; WHERE F NrFact = Soluţia Oracle : SELECT ' ' AS NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) /COUNT(DISTINCT NVL(I Codlnc, )) AS Facturat, SUM(NVL(Transa, )) / MAX(LF Linie) AS încasat FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact (+) AND F NrFact = Care sunt valorile facturate şi încasate ale fiecărei facturi? Şi acesta este un caz rezolvat incomplet în capitolul anterior (la prezentarea clauzei GROUP BY) Ambele soluţii prezentate în continuare conduc către un rezultat de forma celui din figura NRFACT FACTURAT ÎNCASAT                                               Soluţia SQL- , DB şi VFP (în VFP se înlocuieşte VALUE cu NVL): SELECT F NrFact, SUM(Cantitate  PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I CodInc,l)) AS Facturat, SUM(VALUE(Transa, ))/ MAX(LF Linie) AS încasat FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr = P CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact GROUP BY F NrFact Soluţia Oracle : SELECT F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT NVL(I Codlnc, )) AS Facturat, SUM(NVL(Transa, )) / MAX(LF Linie) AS încasat FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact (+) GROUP BY F NrFact Care au fost sporurile de noapte acordate angajaţilor pe lunile mai şi iunie ? Situaţia obţinută se referă la două luni Există însă angajaţi care nu au acest spor pe una sau chiar pe ambele luni Cu interogarea: SELECT AN, Luna, PERSONAL Marca, NumePren, SporNoapte FROM PERSONAL , SPORURI WHERE PERSONAL Marca=SPORURI Marca AND an= AND Luna IN ( , ) ORDER BY NumePren, An, Luna rezultatul arată ca în figura AN LUNA MARCA NUMEPREN (SPORNOAPTE    ANGAJAT      ANGAJAT      ANGAJAT      ANGAJAT j      ANGAJAT j      ANGAJAT   NJ O O O   ANGAJAT      ANGAJAT     ANGAJAT    Figura Sporurile de noapte pe mai şi iunie - varianta de afişare Pentru acest exemplu, interesează însă formatul de prezentare din figura o > NUMEPREN SPORNOAPTE MAI SPORNOAPTEJUNIE   ANGAJAT     ANGAJAT     ANGAJAT     ANGAJAT o    ANGAJAT     ANGAJAT     ANGAJAT     ANGAJAT     ANGAJAT     ANGAJAT     Figura Sporurile de noapte pe mai şi iunie - rezultatul dorit Schimbăm alura SELECT-ului: SELECT AN, Luna, PERS NAL Marca, NumePren, SporNoapte FROM PERS NAL LEFT OUTER JOIN SPORURI ON PERS NAL Marca=SPORURI Marca AND An= AND Luna= ORDER BY NumePren, An, Luna Se obţine astfel tabela din figura Elementul îmbucurător este că în rezultat au fost incluşi toţi angajaţii Cei care nu erau angajaţi în această perioadă prezintă valori NULL pentru atributele An şi Luna Pentru afişarea pe coloane separate a sporurilor de noapte pe lunile mai şi iunie (ca în figura ) sunt necesare două joncţiuni externe ale tabelei PERSONAL cu două instanţe ale tabelei SPORURI AN LUNA MARCA jNUMEPREN SPORNOAPTE    | ANGAJAT     ANGAJAT • „     ANGAJAT     ANGAJAT     i THEN 'Au spor CD' ELSE 'Nu au spor CD' END, COUNT(*) AS Nr FROM SPORURI WHERE An= AND Luna= GROUP BY CASE WHEN SporCD > THEN 'Au spor CD' ELSE 'Nu au spor CD' END Soluţia Oracle „tradiţională” are nevoie de un mic truc pentru ca în DECODE să transformăm intervalele în listă De aceea se scade din NVL(SporCD, ) şi, dacă rezultatul are semnul +, înseamnă că s-a acordat sporul respectiv, iar în caz contrar că nu s-a acordat: SELECT DECODE(SIGN( NVL(SporCD, )- ), , 'Au spor CD', 'Nu au spor CD') AS Poziţionare, COUNT(*) AS NrClienti FROM SPORURI WHERE An= AND Luna= GROUP BY DECODE(SIGN( NVL{SporCD, )- ), , 'Au spor CD', 'Nu au spor CD') Soluţia VFP: SELECT IIF(SporCD > , 'Au spor CD', 'Nu au spor CD'), ; COUNT(*) AS Nr ; FROM SPORURI ; WHERE An= AND Luna= ; GROUP BY Scadenţa fiecărei facturi emise este de de zile Dacă însă data-limită cade într-o sâmbătă sau dtiminică, atunci scadenţa se mută în lunea următoare Care sunt zilele scadente în aceste condiţii? Soluţia DB se bazează pe funcţia DAYOFWEEK, care întoarce dacă data-argument se referă la duminică, pentru luni pentru sâmbătă DAYNAME afişează numele zilei, iar interogarea următoare va genera rezultatul din figura SELECT NrFact, DataFact, DataFact + DAYS AS Scadental, DAYNAME(DataFact + DAYS) AS NumeZil, CASE WHEN DAYOFWEEK(DataFact + DAYS) = THEN DataFact + DAYS ELSE CASE WHEN DAYOFWEEK(DataFact + DAYS) = THEN DataFact + DAYS ELSE DataFact + DAYS END END AS Scadenta, DAYNAME (CASE WHEN DAYOFWEEK(DataFact + DAYS) = THEN DataFact + DAYS ELSE CASE WHEN DAYOFWEEK(DataFact + DAYS)= THEN DataFact + DAYS ELSE DataFact + DAYS END END ) AS Zi Scadenta FROM FACTURI NRFACT DATAFACT SCADENTA NUMEZI SCADENTA ZI SCADENTA    - -  - - nimu Monday ' - - Monday    - -  - - Monday  - - Monday    - -  - - Monday  - - Monday    - -  - - Monday  - - Monday    - -  - - Tuesday  - - Tuesday    - -  - - Tuesday  - - Tuesday    - -  - - Wednesday  - - Wednesday    - -  - - Thursday  - - Thursday    - -  - - Sunday  - - Monday    - -  - - Suriday  - - Monday    - -  - - Sunday  - - Monday    - -  - - Sunday  - - Monday  Figura Scadenţa rectificată a încasării facturilor Soluţia Oracle i este una ceva mai simplă, un rol decisiv avându-l, pe lângă structura CASE, puternica funcţie TO CHAR: SELECT NrFact, TO CHAR(DataFact, 'YYYY-MM-DD') AS DataFact, TO CHAR(DataFact + ,'YYYY-MM-DD') AS Scadental, TO CHAR(DataFact + ,'DAY') AS NumeZil, CASE WHEN TO CHAR(DataFact + ,'DAY') = 'SATURDAY' THEN TO CHAR(DataFact + ,'YYYY-MM-DD') ELSE CASE WHEN TO CHAR(DataFact + ,'DAY') = 'SUNDAY' THEN TO CHAR(DataFact + ,'YYYY-MM-DD') ELSE TO CHAR(DataFact + ,'YYYY-MM-DD') END END AS Scadenta, TO CHAR( CASE WHEN TO CHAR (DataFact + ,'DAY') = 'SATURDAY' THEN DataFact + ELSE CASE WHEN TO CHAR(DataFact + ,'DAY') = 'SUNDAY' THEN DataFact + ELSE DataFact + END END, 'DAY') AS Zi Scadenta FROM FACTURI Visual FoxPro prezintă funcţiile CDOW (Character Day Of the Week) şi DOW (Day Of the Week), rezultatul din figura fiind obţinut după cum urmează: SELECT NrFact AS Factura, DataFact, ; DataFact + AS Scadental, ; CDOW(DataFact+ ) AS NumeZil, ; IIF(DOW(DataFact+ )= , ; DataFact+ , , IIF(DOW(DataFact+ )= , ; DataFact+ , , DataFact+ ) ) AS Scadenta, ; CDOW(IIF(DOW(DataFact+ )= , ; DataFact+ , ; IIF(DOW(DataFact+ )= , ; DataFact+ , ; DataFact+ ) ) ) AS Zi Scadenta ; FROM FACTURI Să se afişeze în dreptul fiecărei facturi: valoarea facturată, valoarea încasată, diferenţa de încasat, precum şi un text din care să reiasă dacă factura este fără nici o încasare, încasată parţial sau încasată total (şi cele trei valori) Practic, se doreşte o situaţie cum este cea din figura NRFACT FACTURAT ÎNCASAT DIFERENŢA SITUATIUNE      ÎNCASATA TOTAL      încasata parţial    G S   ÎNCASATA TOTAL      Fara nici o incasare      Fars nici o incasare      Fara nici o incasare      ÎNCASATA TOTAL      ÎNCASATA TOTAL      Fara nici o incasare      încasata parţial      Fara nici o incasare  Figura , Situaţia încasării facturilor FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr = P CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact GROUP BY F NrFact şi una cei puţin la fel de năucitoare în Oracle: SELECT F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT NVL( I CodInc,l)) AS Facturat, SUM(NVL(Transa, ))/ MAX(LF Linie) AS încasat, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT (DISTINCT NVL ( I Codlnc, )) - SUM(NVL(Transa, ))/ MAX(LF Linie) AS Diferenţa, DECODE (SUM(NVL(Transa, ))/ MAX(LF Linie), , 'Fara nici o incasare', DECODE ( SIGN(SUM(Cantitate * PretUnit * ( +ProcTVA)) COUNT(DISTINCT NVL( I CodInc,l)) - SUM(NVL(Transa, )) / MAX(LF Linie)), , 'ÎNCASATA TOTAL', 'încasata parţial '’;,/ AS Situatiune FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact Al F NrFact=I NrFact (+) GROUP BY'F NrFact Ne-am folosit de acest exemplu (şi) pentru a include o funcţie DECODE în alta Din păcate, în VFP, soluţia: SELECT F NrFact, ; SUM(Cantitate * PretUnit * ( +ProcTVA)) / ; COUNT(DISTINCT NVL( I Codlnc, )) AS Facturat, ; SUM(NVL(Transa, ))/ MAX(LF Linie) AS încasat, , SUM(Cantitate * PretUnit * { +ProcTVA)) / ; COUNT(DISTINCT NVL( I Codlnc, )) - ; SUM(NVL(Transa, ))/ MAX(LF,Linie) ; AS Diferenţa, ; IIF(SUM(NVL(Transa, ))/ MAX(LF,Linie)= , ; 'Fara nici o incasare', ; IIF(SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT NVL( I CodInc,l)) > ; SUM(NVL(Transa, ))/ MAX(LF Linie), ; 'încasata parţial', 'ÎNCASATA TOTAL' )) ; AS Situatiune ; FROM LINIIFACT LF ; INNER JOIN PRODUSE P ON LF,CodPr = P CodPr ; INNER JOIN FACTURI E ON LF NrFact = F NrFact ; LEFT OLiER JOIN INCASFACT I ON F,NrFact=I NrFact GROUP BY F NrFact se loveşte de un obstacol pe care l-am cunoscut în capitolul precedent: operatorul DISTINCT nu poate fi întrebuinţat decât o singură dată pe consultare/subconsultare O variantă de lucru ar fi secvenţa următoare, dar rezultatul este unul mult mai puţin spectaculos, după cum se observă în figura SELECT F NrFact, ; IIF(SUM(NVL(Transa, ))/ MAX(LF Linie)= , ; 'Fara nici o incasare', ; IIF(SUM(Cantitate * PretUnit * ( +ProcTVA)) / ; COUNT(DISTINCT NVL( I CodInc,l)) > ; SUM(NVL(Transa, ))/ MAX(LF Linie), ; 'încasata parţial', 'ÎNCASATA TOTAL ' )) ; AS Situatiune ; FROM LINIIFACT LF ; INNER JOIN PRODUSE P ON LF CodPr = P CodPr ; INNER JOIN FACTURI F ON LF NrFact ='F NrFact ; LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact ; GROUP BY F NrFact Situatiune ÎNCASATA TOTAL încasata parţial ÎNCASATA TOTAL Fara nici o incasare TÎTfiNCASĂTATOTĂL ÎNCASATA TOTAL încasata paitial Figura Situaţia încasării facturilor - răspuns parţial în VFP Aceasta nu înseamnă că problema este insolubilă în VFP, ci doar că trebuie să recurgem la o altă variantă, după cum vom vedea cu alt prilej Soluţia fără CASE, DECODE, IIF Problema poate fi rezolvată şi fară operatorii pentru codarea structurilor alternative, prin reuniunea facturilor fără nici o tranşă încasată cu facturile încasate parţial şi cu facturile încasate total Din raţiuni de economie de spaţiu, este prezentată în continuare numai varianta DB (SQL- ): SELECT F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I Codlnc, )) AS Facturat, SUM(VALUE(Transa, ))/ MAX(LF Linie) AS încasat, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I CodInc,l)) - SUM(VALUE(Transa, ))/ MAX(LF Linie) AS Diferenţa, 'Fara nici o incasare' AS Situatiune FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr = P CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact GROUP BY F NrFact HAVING SUM(VALUE(Transa, ))/ MAX(LF Linie) = UNION SELECT F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I Codlnc, )) AS Facturat, SUM(VALUE(Transa, ))/ MAX(LF Linie) AS încasat, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I CodInc,l)) - SUM(VALUE(Transa, ))/ MAX(LF Linie), 'încasata parţial' FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr = P CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact GROUP BY F NrFact HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I Codlnc, )) > SUM(VALUE(Transa, ))/ MAX(LF Linie) AND SUM(VALUE(Transa, ))/ MAX(LF Linie) O UNION SELECT F NrFa-ct, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I Codlnc,!)) AS Facturat, SUM(VALUE(Transa, ))/ MAX(LF Linie) AS încasat, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I Codlnc, )) - SUM(VALUE(Transa, ))/ MAX(LF Linie), 'ÎNCASATA TOTAL' FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr =, P CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact GROUP BY F NrFact HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I Codlnc, )) = SUM(VALUE(Transa, ))/ MAX(LF Linie) Subconsultări Operatorul IN Una din cele mai importante facilităţi ale SQL constă în includerea unei consultări în alta, pe două sau mai multe niveluri - altfel spus, utilizarea subconsultărilor Prin subconsultări se obţin tabele temporare intermediare folosite ca „argumente” ale frazelor SELECT superioare Operatorul cel mai utilizat în materie de subconsultări este IN, pe care l-am întâlnit deja în capitolul precedent într-o cu totul altă ipostază - testarea încadrării valorii unui atribut într-o listă de constante Pentru, cele ce urmează, domeniul de testare este alcătuit din liniile unei tabele obţinute printr-o (sub)consultare Revenim (pentru a doua oară) la exemplul din algebra relaţională: Ce facturi au fost emise în aceeaşi zi cu factura ? In capitolul anterior a fost formulată o soluţie bazată pe joncţiunea a două instanţe ale tabelei FACTURI Iată şi o soluţie mai simplă, bazată pe subconsultări: SELECT NrFact FROM FACTURI WHERE DataFact IN {SELECT DataFact FROM FACTURI WHERE NrFact= ) Exectţla acestei interogări se derulează în doi timp Mai întâi se execută subconsultarea SELECT "oataFact FROM FACTURI WHERE NrFact= , obţinându-se o tabelă intermediară cu o singură linie (pe care apare - - ) şi o singură coloană (OataFact), ca în figura în al doilea pas sunt selectate liniile tabelei FACTURI care îndeplinesc condiţia Da ta Fact = ' - - ' FACTOR* | KiFact DsiaFact CodCl Obs  l  / /  NULL    / /  Probleme cu transportul    / /  NULL    / /  NULL    / /  NULL    / /  Preţul propus iniţial a fost modificat    / /  NULL    / /  NULL    / /  NULL    / /  NULL    / /  NULL    / /  NULL   în rezultat a fost inclusă şi factura de referinţă - Dacă se doreşte excluderea acesteia, fraza SELECT se modifică astfel: SELECT NrFact FROM FACTURI WHERE DataFact IN (SELECT DataFact FROM FACTURI WHERE NrFact= ) AND NrFact O Ce facturi au fost emise în alte zile decât factura ? Acest exemplu necesită folosirea operatorului de negaţie: SELECT NrFact FROM FACTURI WHERE DataFact NOT IN (SELECT DataFact FROM FACTURI WHERE NrFact= ) Care simt clienţii cărora li s-au trimis facturi în aceeaşi zi în care a fost întocmită factura ? SELECT DenCl FROM CLIENŢI WHERE CodCI IN (SELECT CodCI FROM FACTURI WHERE DataFact IN (SELECT DataFact FROM FACTURI WHERE NrFact= )) Rezultatul prezentat în figura se obţine folosind trei niveluri de interogare (fraza principală o subconsultare şi o sub-subconsultare) DENCL - Client SRL Client SRL Client Client SRL Figura Clienţii pentru care există facturi emise în aceeaşi zi ca Dacă în DB şi Oracle această ultimă interogare este executată fară probleme, în VFP facem cunoştinţă” cu una dintre cele mai serioare limitări SQL - maximum două niveluri de consultare (fraza principală şi o interogare subordonată) Mesajul de eroare are numărul : SQL; Subquery nesting is too deep Astfel, pentru a răspunde la întrebare, soluţia de interogare trebuie reformulată: SELECT DenCl ; FROM CLIENŢI INNER JOIN FACTURI ; ON CLIENŢI CodCl=FACTURI CodCI ; WHERE DataFact IN ; (SELECT DataFact ; FROM FACTURI ; WHERE NrFact= ) în ce judeţe s-a vândut produsul „ Produs ”? Am ales acest exemplu pentru a „vântura”, prin subconsultări, cât mai multe tabele ale bazei (rezultatul - vezi figura ): SELECT Judeţ FROM JUDEŢE WHERE Jud IN (SELECT Jud FROM LOCALITATI WHERE CodPost IN (SELECT CodPost FROM CLIENŢI WHERE CodCI IN (SELECT CodCI FROM FACTURI WHERE NrFact IN (SELECT NrFact FROM LINIIFACT WHERE CodPr IN (SELECT CodPr FROM PRODUSE WHERE DenPr = 'Produs ' ) ) ) ) ) JUDEŢ lasi Neamţ Timiş Vaslui Figura Judeţele în care s-a vândut „Produs ” Revenim la tabela PERSONAL din figura : Câţi subordonaţi direcţi are ANGAJAT ? La această problemă (la care răspunsul este ) formulăm, pentru comparaţie, două soluţii Soluţia bazată pe joncţiune este: SELECT COUNT(*) AS NrSubordonati FROM PERSONAL SUBORDONAŢI, PERSONAL SEFI WHERE SUBORDONAŢI MarcaSef=SEFI Marca AND SEFI NumePren='ANGAJAT ' A doua soluţie utilizează o subconsultare: SELECT COUNT(Marca) AS NrSubordonati FROM PERSONAL WHERE MarcaSef IN (SELECT Marca FROM PERS NAL WHERE NumePren='ANGAJAT ') în capitolul am cheltuit destul de puţin timp şi spaţiu pentru un tip de joncţiune nu prea folosit semijoncţiunea, prin care se extrag numai liniile dintr-o tabelă ce au corespondent (ca valoare a atributului de legătură) în a doua tabelă Cu operatorul IN se pot formula lejer soluţii ce corespund semijoncţiunii Astfel, o tabelă precum cea din figura se obţine prin: SELECT * FROM Rl WHERE C IN (SELECT C FROM R ) Completam discuţia şi cu exemplul „practic” luat pentru ilustrarea semijoncţiunii (exemplul din capitolul ): Care sunt localităţile (codul poştal, denumirea şi indicativul judeţului) în care exista macar un client? SELECT * FROM LOCALITATI WHERE CodPost IN (SELECT CodPost FROM CLIENŢI) CODPOST LOC JUD   Timişoara TM   Roman NT   Paşcani IS   Vaslui VS   lasi IS  Figura Localităţi în care există măcar un client Tot prin subconsultări putem realiza intersecţia şi diferenţa relaţională Raportându-ne la exemplul teoretic din capitolul (figura ), intersecţia celor două relaţii, Rl şi R , se poate obţine şi astfel: F SELECT * FROM Rl WHERE (A,B,C) IN (SELECT C,D,E FROM R ) Varianta funcţionează în DB şi Oracle, nu însă şi în VFP, deoarece într-o subconsultare nu pot fi testate simultan trei valori (ale atributelor A, B şi C), ci numai una Atfel încât, pentru a-i înşela vigilenţa, vom concatena cele trei atribute, dând senzaţia că avem de-a face cu unul singur- SELECT * ; FROM R ; WHERE STR(A, )+B+STR(C, ) IN ; (SELECT STR(C, )+D+STR(E, ) ; FROM R ) Un alt exemplu de intersecţie (exemplul - algebra relaţională): în ce zile s-au vândut şi produsul cu denumirea „ Produs ”, şi cel cu denumirea „ Produs ? SELECT DISTINCT DataFact FROM PRODUSE, LINIIFACT, FACTURI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND DenPr = 'Produs ' AMD DataFact IN (SELECT DISTINCT DataFact FROM PRODUSE, LINIIFACT, FACTURI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND DenPr = 'Produs ') Cât priveşte diferenţa relaţională, cheia rezolvării este NOT IN Diferenţa relaţiilor R şi R , prezentată în figura , poate fi calculată în SQL astfel: SELECT * FROM R WHERE (A,B,C) NOT IN {SELECT C,D,E FROM R ) Fireşte, în VFP vom aplica „trucul” concatenării, ca şi la intersecţie Apelăm iarăşi la un exemplu din algebra relaţională (exemplul ): Ce clienţi au cumpărat şi „ Produs ”, şi „ Produs ", dar nu au cumpărat „ Produs ”? Soluţia comună SQL- /DB /Oracle/Visual FoxPro este: SELECT DISTINCT DenCl FROM PRODUSE, LINIIFACT, FACTURI, CLIENŢI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND FACTURI CodCl = CLIENŢI CodCl AND DenPr = 'Produs ' AND FACTURI CodCl IN (SELECT CodCl FROM PRODUSE, LINIIFACT, FACTURI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND DenPr = 'Produs ") AND FACTURI CodCl NOT IN (SELECT CodCl  mm FROM PRODUSE, LINIIFACT, FACTURI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI„NrFact AND DenPr = 'Produs ') Până la apariţia operatorilor LEFT OUTER JOIN, RIGHT OUTER JOIN şi FULL OUTER JOIN, în multe SGBD-uri joncţiunea externă era realizată prin reuniunea liniilor obţinute din echi-joncţiune cu liniile unei tabele (completate cu zerouri/spaţii pentru atributele celeilalte tabele) ce nu au corespondent în cealaltă Cum joncţiunea externă a fost definită în capitolul , revenim la operaţiunea ilustrată în figura Joncţiunea externă la stânga a relaţiilor Rl şi R prin atributul C ar putea fi realizată şi astfel: SELECT * FROM Rl, R WHERE Rl C = R C UNION SELECT A,B,C, , * FROM Rl WHERE C NOT IN (SELECT C FROM R ) Varianta de mai sus funcţionează în toate cele trei SGBD-uri La drept vorbind, soluţia pe care am încercat-o prima dată şi care ar fi corespuns pe deplin joncţiunii externe era: SELECT * FROM Rl, R WHERE Rl C = R C UNION ' SELECT A,B,C, NULL, NULL, NULL FROM Rl WHERE C NOT IN (SELECT C FROM R ) însă toate cele trei SGBD-uri se încăpăţânează să nu o execute Revenim la câteva exemple prezentate la joncţiunea externă pe care le rezolvăm prin noua „reţetă” - reuniune/valori vide Care sunt valorile facturate şi încasate ale fiecărei facturi? Soluţia de mai jos (valabilă deopotrivă în DB , Oracle şi VFP) reuneşte facturile care au măcar o tranşă de încasare cu cele neîncasate deloc SELECT F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT I Codlnc) AS Facturat, SUM(Transa) / MAX(LF Linie) AS încasat FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact GROUP BY F NrFact UNION SELECT F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat, AS încasat FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact NOT IN (SELECT NrFact FROM INCASFACT) GROUP BY F NrFact Să se obţină sporurile de noapte pentru al doilea trimestru al anului , atât lunar, cât şi cumulat Trebuie reunite persoanele care au sporul de noapte pe toate cele trei luni cu persoanele care prezintă sporul numai pe câte două luni şi cu persoanele cu sporul pe o singură lună Dacă la momentul formulării soluţiei anterioare afirmam că fraza SELECT este supraponderală, prezenta soluţie este pur şi simplu pantagruelică Cred că fraza următoare (care funcţionează în DB şi Oracle) demonstrează fără dubii că joncţiunea externă este o găselniţă grozav de inteligentă şi, pe de altă parte, că scrierea frazelor SQL poate deveni, pe alocuri, o treabă înfricoşătoare SELECT PERSONAL Marca, NumePren, SI SporNoapte AS Spor Noapte Aprilie, S SporNoapte AS Spor Noapte Mai, S SporNoapte AS Spor Noapte Iunie, SI SporNoapte + S SporNoapte + S SporNoapte AS Spor Noapte Trim II FROM PERSONAL , SPORURI SI, SPORURI S , SPORURI S WHERE PERSONAL Marca=Sl Marca AND Sl An= AND =Sl Luna AND PERSONAL Marca=S Marca AND S An= AND =S Luna AND PERS NAL Marca=S Marca AND S An= AND = S Luna UNION SELECT PERSONAL Marca, NumePren, SI SporNoapte, S SporNoapte, , SI SporNoapte + S SporNoapte FROM PERSONAL , SPORURI SI, SPORURI S WHERE PERSONAL Marca=Sl Marca AND An= AND = SI Luna AND PERSONAL Marca=S Marca AND An= AND = S Luna AND PERSONAL Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) UNION SELECT PERSONAL Marca, NumePren, SI SporNoapte, , ■ :ili SQL (CEVA MAI) AVANSAT S SporNoapte, SI SporNoapte + S SporNoapte FROM PERS NAL , SPORURI SI, SPORURI S WHERE PERS NAL Marca=Sl Marca AND Sl An= AND = SI Luna AND PERS NAL Marca=S Marca AND S An= AND = S Luna AND PERS NAL Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) UNION SELECT PERS NAL Marca, NumePren, , S SporNoapte, S SporNoapte, S SporNoapte + S SporNoapte FROM PERSONAL , SPORURI S , SPORURI S WHERE PERSONAL Marca=S Marca AND S An= AND = S Luna AND PERSONAL Marca=S Marca AND S An= AND = S Luna AND PERSONAL Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) UNION SELECT PERSONAL Marca, NumePren, SI SporNoapte, , , SI SporNoapte FROM PERSONAL , SPORURI SI WHERE PERSONAL Marca=Sl Marca AND =Sl An AND = SI Luna AND PERSONAL Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) AND PERSONAL Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) UNION SELECT PERSONAL Marca, NumePren, , S SporNoapte, , S SporNoapte FROM PERSONAL , SPORURI S WHERE PERS NAL Marca=S Marca AND =S An AND = S Luna AND PERS NAL Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) AND PERSONAL Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) UNION SELECT PERSONAL Marca, NumePren, , , S SporNoapte, S SporNoapte FROM PERSONAL , SPORURI S WHERE PERSONAL Marca=S Marca AND =S An AND = S Luna AND PERSONAL Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) AND PERSONAL Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) UNION SELECT PERSONAL Marca, NumePren, , , , FROM PERSONAL WHERE Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) AND Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) AND Marca NOT IN (SELECT Marca FROM SPORURI WHERE An= AND Luna= ) ORDER BY NumePren Cred că singura mângâiere este că am scris, de voie, de nevoie, cea mai lungă frază SELECT de până acum Tot cu ajutorul operatorului IN (şi NOT IN) se poate aborda şi „problema” diviziunii relaţionale în SQL (parcă vă aud spunând: „Asta ne mai lipsea acuma!”) Succesiunea de paşi prezentată în figura se realizează relativ simplu prin soluţia SQL- /DB : SELECT X FROM Rl EXCEPT SELECT DISTINCT Rl X FROM Rl, R WHERE (Rl X, R Y) NOT IN (SELECT X, Y FROM Rl) în Oracle este necesară înlocuirea operatorului EXCEPT cu MINUS Cu VFP e o poveste mai lungă Cum aici nu există nici EXCEPT, nici MINUS, sau ceva similar, am încercat varianta: SELECT  ; FROM Rl, R ; WHERE R X+R Y NOT IN ; (SELECT X+Y ; FROM Rl) Mesajul primit a fost unul curat, limpede, tonic şi explicit ca al unui funcţionar de la ghişeele Oficiilor Forţelor de Muncă: SQL: Queries of this type are not supported (Error ) Ce-i de făcut? Salvarea vine tot de Ia joncţiunea externă: SELECT DISTINCT X ; FROM Rl ; WHERE X+' ' NOT IN ; (SELECT Rl l X + NVL(Rl X,' ') ; FROM Rl Rl l ; INNER JOIN R R l ON = ; LEFT OUTER JOIN Rl Rl ; ON Rl l X=R X AND R l Y=R Y) Pseudojoncţiunea internă este de fapt un produs cartezian, deoarece condiţia de joncţiune este = Subconsultarea extrage „icşii” care au „goluri”, iar fraza SELECT principală efectuează scăderea lor din „icşii” tabelei Rl Aflaţi clienţii pentru care există cel puţin câte o factură emisă în fiecare zi Acesta este exemplul din algebra relaţională (figura ) pentru ilustrarea operatorului diviziune Urmăm logica pe care tocmai am prezentat-o WHERE C CodCl=Fl CodCl AND (C CodCl, F DataFact) NOT IN (SELECT C CodCl, DataFact FROM CLIENŢI C, FACTURI F WHERE C CodCl=F CodCl)) Soluţia VFP: SELECT DISTINCT DenCl ; FROM CLIENŢI ; INNER JOIN FACTURI ON CLIENŢI CodCl=FACTURI CodCl ; WHERE STR(CLIENTI CodCl, }+STR( , ) NOT IN ; (SELECT STR (FI CodCl, -) +STR(NVL (F CodCl, ) , ) ; FROM FACTURI FI INNER JOIN FACTURI F ON = ; LEFT OUTER JOIN FACTURI F ON ; FI CodCl=F CodCl AND F DataFact=F DataFact) In ce zile s-au vândut şi produsul cu denumirea „ Produs I ”, şi cel cu denumirea ,, Produs ”? Este exemplul din acelaşi capitol Soluţia DB (şi Oracle, înlocuind EXCEPT cu MINUS): SELECT DataFact FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr AND DenPr IN ('Produs ', 'Produs ') EXCEPT ; SELECT DISTINCT F DataFact FROM FACTURI F, LINIIFACT LF, PRODUSE PI, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=Pl CodPr AND PI DenPr IN ('Produs ', 'Produs ') AND P DenPr IN ('Produs ', 'Produs ') AND (F DataFact, P CodPr) NOT IN (SELECT DISTINCT DataFact, LF CodPr FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr AND DenPr IN ('Produs ', 'Produs ')) Soluţia VFP: SELECT DISTINCT DataFact ; FROM FACTURI ; INNER JOIN LINIIFACT ON FACTURI NrFact=LINIIFACT NrFact INNER JOIN PRODUSE ON LINIIFACT CodPr=PRODUSE CodPr AND DenPr IN ( Produs ', 'Produs ') ; WHERE DTOC(DataFact)+DTOC({//}) NOT IN ; (SELECT DISTINCT DTOC(FI DataFact)+; DTOC(NVL(F DataFact, {//})); FROM FACTURI FI INNER JOIN PRODUSE PI ; ON PI DenPr IN ('Produs ','Produs ') ; LEFT OUTER JOIN (LINIIFACT LF INNER JOIN FACTURI F  ON LF NrFact=F NrFact) ; ON FI DataFact=F DataFact AND PI CodPr=LF CodPr) Prezenta soluţie mi-a prilejuit descoperirea unei facilităţi pe care alţii, probabil, o ştiau de mult Şi în VFP este posibilă joncţionarea unei tabele cu rezultatul unei alte joncţiuni, precedenţa joncţionărilor fiind indicată cu ajutorul parantezelor Fără această opţiune, lucrurile ar fi avut un aer mult mai grav încheiem paragraful dedicat operatorului IN cu un exemplu mai puţin „colţuros”, dar suficient de interesant Să se afişeze câte facturi sunt: neîncasate deloc, încasate parţial şi încasate total? Soluţia reuneşte facturile încasate total cu facturile încasate parţial şi cu facturile neîncasate deloc SELECT 'încasate TOTAL' AS Situatiune, COUNT(*) AS Nr FROM FACTURI WHERE NrFact IN (SELECT F Nrfact FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact GROUP BY F NrFact HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT I Codlnc) = SUM(Transa) / MAX(LF Linie)) UNION SELECT 'încasate parţial', COUNT(*) FROM FACTURI WHERE NrFact IN (SELECT F NrFact FROM LINIIFACT LF, PRODUSE P, FACTURI F, INCASFACT I WHERE LF CodPr = P CodPr AND LF NrFact = F NrFact AND F NrFact=I NrFact GROUP BY F NrFact HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT I Codlnc) > SUM(Transa) / MAX(LF Linie)) UNION SELECT 'Neincasate deloc', COUNT(*) FROM FACTURI WHERE NrFact IN (SELECT NrFact FROM LINIIFACT) AND NrFact NOT IN (SELECT NrFact FROM INCASFACT) SITUATIUNE NR  încasate TOTAL   încasate parţial   Neincasate deloc    Figura Numărul facturilor fără nici o tranşă de încasare, încasate parţial şi încasate total Până acum subconsultările au fost conectate la fraza SELECT superioară exclusiv prin operatorul IN în paragraful următor vom vedea că pentru (sub)interogările comparative pot fi întrebuinţaţi ALL, SOME, ANY Atunci când rezultatul unei subconsultări se concretizează într-o tabelă cu o singură coloană şi o singură linie, corelarea poate fi făcută cu operatorii de comparaţie obişnuiţi: = , >, >=, = (SELECT MAX(PretUnit) FROM LINIIFACT WHERE PretUnit (SELECT MAX(PretUnit) FROM LINIIFACT WHERE PretUnit , =, sau# Dacă, în cea mai mare parte a cazurilor de până acum, se compara un atribut (sau rezultatul unei expresii/funcţii) cu o constantă, ALL, SOME şi ANY permit compararea valorii atributului/funcţiei/expresiei cu un set de tupluri (absamblu de linii) extras printr-o subconsultare Care sunt produsele vândute la preţuri unitare superioare oricărui preţ unitar la care a fost vândut „Produs ”? Soluţia acestei probleme este valabilă în SQL- şi în toate cele trei SGBD-uri: SELECT DISTINCT DenPr FROM PRODUSE P, LINIIFACT LF WHERE P CodPr=LF CodPr AND PretUnit > ALL (SELECT DISTINCT PretUnit FROM PRODUSE P, LINIIFACT LF WHERE P CodPr=LF CodPr AND DenPr ='Produs ') Ca orice interogare pe două niveluri, ostilităţile se derulează în doi paşi Mai întâi se execută subconsultarea şi se obţine o tabelă intermediară în care se găsesc toate preţurile unitare la care a fost vândut, în decursul istoriei, Produs - vezi figura PRETUNIT Figura Rezultatul subconsultării - preţurile unitare pentru „Produs ” Cum operatorul de conexiune a frazei SELECT principale cu subconsultarea este > ALL, din joncţiunea tabelelor PRODUSE şi LINIIFACT vor fi extrase numai liniile care au valoarea atributului PretUnit mai mare decât toate valorile din figura Aşa încât rezultatul final se prezintă ca în figura DENPR Produs Produs Care sunt produsele vândute la preţuri unitare superioare măcar unui preţ unitar al „ Produsului ”? Este genul de situaţii în care se foloseşte SOME sau ANY (au aceeaşi funcţiune) SELECT DISTINCT DenPr FROM PRODUSE P, LINIIFACT LF WHERE P CodPr=LF CodPr AND PretUnit > ANY (SELECT DISTINCT PretUnit FROM PRODUSE P, LINIIFACT LF WHERE P CodPr=LF CodPr AND DenPr ='Produs ') Rezultatul este cel din figura , deoarece, spre deosebire de ALL, şi ANY (şi SOME) selectează liniile pentru care preţul unitar este mai mare decât măcar una dintre valorile obţinute prin subconsultare DENPR Produs Produs Produs Figura Produse cu cel puţin un preţ unitar superior măcar unui preţ unitar al „Produsului “ Operatorul =ANY este echivalent cu IN Câţi alţi angajaţi au salariul tarifar egal cu al ANGAJAT ? Soluţia: SELECT COUNT(*) - AS Nr FROM PERSONAL WHERE SalTarifar IN (SELECT Saltarifar FROM PERSONAL WHERE NumePren='ANGAJAT ') este echivalentă cu: SELECT COUNT(*) - AS Nr FROM PERSONAL WHERE SalTarifar =ANY (SELECT Saltarifar FROM PERSONAL WHERE NumePren='ANGAJAT ') Folosirea unuia din cei trei operatori nu este obligatorie atunci când subconsultarea conţine o funcţie-agregat (ce întoarce o valoare dintr-un ansamblu de tupluri) - MIN, MAX, COUNT, SUM, AVG Care este ultima factură întocmită (factura cea mai recentă) şi data la care a fost emisă? Oricare dintre variantele următoare funcţionează şi obţine valorile din figura DATAFACT jULTIMAFACTURA   - - '   SELECT DataFact, NrFact AS UltimaFactura FROM FACTURI WHERE NrFact IN (SELECT MAX(NrFact) FROM FACTURI) SELECT DataFact, NrFact AS UltimaFactura FROM FACTURI WHERE NrFact = (SELECT MAX(NrFact) FROM FACTURI) SELECT DataFact, NrFact AS UltimaFactura FROM FACTURI WHERE NrFact =ANY (SELECT MAX(NrFact) FROM FACTURI) SELECT DataFact, NrFact AS UltimaFactura FROM FACTURI WHERE NrFact =ALL (SELECT MAX(NrFact) FROM FACTURI) Fără funcţia MAX, soluţia este: SELECT DataFact, NrFact AS UltimaFactura FROM FACTURI WHERE NrFact >= ALL (SELECT NrFact FROM FACTURI) Subconsultări în clauza HAVING Predicatele incluse în clauza HAVING ale interogărilor de până acum compară o expresie cu o constantă In cele ce urmează vom discuta despre includerea în clauza HAVING a subconsultărilor Din păcate, deoarece această facilitate nu a fost încă implementată (până la versiunea VFP ) în nucleul SQL al acestui produs, trimiterile la Visual FoxPro vor fi mai lapidare în acest paragraf Revenim asupra unei probleme formulate în ultima parte a paragrafului : Care sunt zilele în care s-au emis mai multe facturi decât pe august ? Se poate formula o soluţie bazată pe subconsultări în clauza HAVING (prezenta este redactată în DB - în Oracle este necesară funcţia de conversie TO DATE): SELECT DataFact AS Zi, COUNT(NrFact) AS Nr Facturilor FROM FACTURI GROUP BY DataFact HAVING COUNT(NrFact) > (SELECT COUNT (NrF'act) FROM FACTURI WHERE DataFact - ' / / ') Care este ziua în care s-au emis cele mai multe facturi? SELECT DataFact, COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact HAVING COUNT(*) >= ALL (SELECT COUNT(*) FROM FACTURI GROUP BY DataFact) Subconsultarea calculează numărul de facturi corespunzător fiecărei zile Predicatul clauzei HAVING compară numărul de facturi al fiecărei zile cu toate valorile extrase de subconsultare Se obţine tabela din figura DATAFACT NR FACTURILOR   -AUG-    -AUG-    Figura Zilele în care s-au emis cele mai multe facturi Se cuvine de adăugat că Oracle mai permite şi o soluţie bazată pe incluziunea unei funcţii în alta: SELECT DataFact, COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact HAVING COUNT(*) = (SELECT MAX(COUNT(*)) FROM FACTURI GROUP BY DataFact) Am fi nedrepţi cu VFP dacă nu am prezenta o soluţie care mie, unuia, îmi place pentru simplitate Iat-o: SELECT TOP DataFact, COUNT(*) AS Nr ; ' FROM FACTURI ; GROUP BY DataFact ; ORDER BY Nr DESC Surprinzător pentru unii, soluţia funcţionează ORDER BY se aplică grupurilor, iar ordonarea împreună cu opţiunea TOP extrag rezultatul corect Care este clientul care a cumpărat cele mai multe produse? soluţie SQL- /DB /Oracle: SELECT DenCl, COUNT(DISTINCT CodPr) AS CiteProduse FROM CLIENŢI C, FACTURI F, LINIIFACT LF WHERE C CodCl=F CodCI AND F NrFact= LF NrFact GROUP BY DenCl HAVING COUNT(DISTINCT CodPr) >= ALL (SELECT COUNT(DISTINCT CodPr) FROM FACTURI F, LINIIFACT LF WHERE F NrFact= LF NrFact GROUP BY CodCl) DENCL CITEPRODUSE  Client SRL    Figura Clientul care a cumpărat cele mai multe produse alta „Oracle only” (COUNT în MAX): SELECT DenCl, COUNT(DISTINCT CodPr) AS CiteProduse FROM CLIENŢI C, FACTURI F, LINIIFACT LF WHERE C CodCl=F CodCl AND F NrFact= LF NrFact GROUP BY DenCl HAVING COUNT(DISTINCT CodPr) = (SELECT MAX(COUNT(DISTINCT CodPr)) FROM FACTURI F, LINIIFACT LF WHERE F NrFact= LF NrFact GROUP BY CodCl) şi una VFP (clauza TOP): SELECT TOP DenCl, COUNT(DISTINCT CodPr) AS CiteProduse ; FROM CLIENŢI C INNER JOIN FACTURI F ON C CodCl=F CodCl ; INNER JOIN LINIIFACT LF ON F NrFact= LF NrFact ; GROUP BY DenCl ; ORDER BY CiteProduse DESC Care este compartimentul cu cea mai bună medie a salariilor tarifare? Se exclude din discuţie compartimentul DIRECŢIUNE în care apare, singur şi ferice, directorul general • SELECT Compart, AVG(SalTarifar) AS Medie Sal FROM PERSONAL WHERE Compart <> 'DIRECŢIUNE' GROUP BY Compart HAVING AVG(SalTarifar) >= ALL (SELECT AVG(SalTarifar) FROM PERSONAL WHERE Compart O 'DIRECŢIUNE' GROUP BY Compart) COMPART MEDIE SAL  RESURSE UMANE    Pentru aducerea aminte a structurilor alternative, putem folosi şi variantele: SQL- /DB : SELECT Compart, AVG (CASE WHEN Compart <> 'DIRECŢIUNE' THEN SalTarifar ELSE END) AS Medie Sal FROM PERSONAL GROUP BY Compart HAVING AVG (CASE WHEN Compart O 'DIRECŢIUNE' THEN SalTarifar ELSE END) >= ALL (SELECT AVG (CASE WHEN Compart <> 'DIRECŢIUNE' THEN SalTarifar ELSE END) FROM PERS NAL GROUP BY Compart) şi Oracle: SELECT Compart, ROUND(AVG ( DECODE (Compart, 'DIRECŢIUNE', , SalTarifar) ), ) AS Medie Sal FROM PERSONAL GROUP BY Compart HAVING AVG (DECODE (Compart, 'DIRECŢIUNE', , SalTarifar)) >= ALL (SELECT AVG (DECODE (Compart, 'DIRECŢIUNE', , SalTarifar)) FROM PERSONAL GROUP BY Compart) Funcţia ROUND a fost necesară pentru afişarea numai a părţii întregi din medie De data aceasta (şi următoarele) trecem peste varianta Oracle cu funcţie inclusă în altă funcţie în fine, varianta VFP: SELECT TOP Compart, AVG(SalTarifar) AS Medie Sal ; FROM PERSONAL ; WHERE Compart O 'DIRECŢIUNE' ; GROUP BY Compart ; ORDER BY Medie Sal DESC Care este judeţul în care berea s-a vândut cel mai bine? în tabela PRODUSE există un atribut care reprezintă grupa în care se încadrează produsul respectiv Berea este una dintre grupele îndrăgite SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari Bere FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr AND Grupa='Bere' GROUP BY Judeţ HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) >= ALL (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud^L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr AND Grupa='Bere' GROUP BY Judeţ) VINZARI BERE Iasi Figura Judeţul cu cea mai bună vânzare a produselor din grupa Bere Să nu uităm soluţia funcţională în VFP, cuceritoare prin simplitate: SELECT TOP Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA))\ AS Vinzari Bere ; FROM JUDEŢE J INNER JOIN LOCALITATI L ON J Jud=L Jud ; INNER JOIN CLIENŢI C ON L CodPost=C CodPost ; INNER JOIN FACTURI F ON C CodCl=F CodCl ; INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact ; INNER JOIN PRODUSE P ON LF CodPr=P CodPr ; WHERE Grupa='Bere' ; GROUP BY Judeţ ; ORDER BY Vinzari Bere DESC Care sunt clienţii cu valoarea vânzărilor peste medie? SELECT DenCl AS Client, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LINIIFACT LF, PRODUSE P, FACTURI F, CLIENŢI C WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact AND F CodCl=C CodCl GROUP BY DenCl HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) >= (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT F CodCI) FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact) CLIENT VINZARI  Client SRL   Client SRL   Client   Client SA    Figura Clienţi cu vânzări peste medie Extrageţi factura cu valoarea imediat peste cea medie SELECT F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Valoare FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact GROUP BY F NrFact HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT F NrFact) FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact)) AND SUM(Cantitate * PretUnit * ( +ProcTVA)) > (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT F NrFact) FROM LINIIFACT LF, PRODUSE P, FACTURI F WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact) NRFACT VALOARE      Figura Factura cu cea mai mică valoare peste medie Elementul de noutate al acestei interogări este includerea, într-o consultare ce prezintă clauza HAVING, a unei alte subconsultări în care apare, de asemenea, HAVING Pentru VFP nu am nici o variantă la îndemână Care este judeţul cu vânzări imediat superioare judeţului Neamţ? SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY Judeţ HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F,LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr AND Judet='Neamţ')) AND SUM(Cantitate * PretUnit * ( +ProcTVA)) > (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr AND Judet='Neamţ') JUDEŢ VINZARI  Vaslui    Figura Judeţul cu vânzări imediat superioare judeţului Neamţ Care este clientul cel mai mare datornic? Este, cred, cea mai grea interogare de până acum După cum am văzut atunci când am calculat pentru fiecare factură valorile facturate şi încasate, la joncţiunea externă a „părţii de facturare” cu „partea de încasare”, fiecare tranşă de încasare se repetă în funcţie de numărul de linii ce compun factura respectivă, iar fiecare linie a facturii se repetă în funcţie de numărul de tranşe de încasare Trucul utilizat pentru a o scoate la capăt consta în împărţirea totalului tranşelor de încasare la numărul liniilor din factură, obţinând astfel valoarea încasată a facturii şi, pe de altă parte, împărţirea totalului valorilor liniilor din facturi la numărul tranşelor de încasare Pentru problema de faţă trebuie găsită o altă soluţie, deoarece gruparea nu o facem la nivel de factură, ci la nivel de client Numărul de linii din facturi şi numărul de tranşe nu mai au nici o relevanţă la gruparea după client Pentru încasări, ar fi o idee Deoarece o tranşă se repetă pentru fiecare linie a facturii, putem elimina din SUM toate tranşele pentru care Linie > încercăm ceva în DB : SELECT DenCl AS Client, SUM ( CASE WHEN LF Linie > THEN NULL ELSE VALUE(Transa, ) END) AS Valoare Incasata FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr = LF CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact INNER JOIN CLIENŢI C ON F CodCI = C CodCI LEFT OUTER JOIN INCASFACT I ON F Nrfact=I NrfACT GROUP BY DenCl Rezultatul din figura ne încredinţează că ideea n-a fost chiar rea CLIENT VALOAR E IN CASATA  Clienţi SRL   Client SA   Client SRL   Client   Client SRL   Cliente SA   Client SRL   Figura încasările pe clienţi (DB ) Cu valoarea facturată însă, lucrurile sunt mai complicate Fiecare linie din factură se repetă de atâtea ori, în funcţie de câte tranşe de încasare există pentru factura respectivă Cum gruparea se face pe clienţi, numărul tranşelor este irelevant Trebuie însumate valorile distincte ale facturii şi liniei Este adevărat, clauza DISTINCT poate fi folosită şi cu SUM Dar este aproape sigur vă vom avea, la un moment dat, două linii, în aceeaşi factură, cu aceeaşi valoare E musai de însumat valorile expresiei pentru combinaţii distincte (NrFact, Linie) Confirmând vocaţia de popor de improvizatori (n-am zis cârpaci, să nu supăr adevăraţii patrioţi), recurgem la un truc ieftin, dar, vorba dlui Graur (comentatorul), năucitor! SELECT DenCl, SUM( DISTINCT * LF NrFact + - * LF Linie + Cantitate * PretUnit * ( +ProcTVA)) AS Valoare Facturata FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr = LF CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact INNER JOIN CLIENŢI C ON F CodCI = C CodCI LEFT OUTER JOIN INCASFACT I ON F Nrfact=I NrfACT GROUP BY DenCl Nu putem discuta detalii înainte de a vedea ce a putut fi obţinut din interogare - figura DENCL VALOARE FACTURATA  Clienţi SRL   Client SA   Client SRL   Client   Client SRL   Client SA   Client SRL    Figura Improvizaţie pentru calculul valorii vânzărilor pe clienţi (DB ) Expresia de calcul a valorii facturate introduce, pe lângă Cantitate, PretUnit şi ProcTVA, şi NrFact şi Linie Ultimele două atribute sunt înmulţite cu constante foarte mari ( biliard, respectiv bilioane), suficient de mari pentru ca valoarea propriu-zisă a facturilor să nu fie „afectată” Este sigur că valorile obţinute pentru fiecare client au fost calculate luându-se în calcul o singură dată fiecare linie dintr-o factură Iar dacă privim în rezultat partea din dreapta fiecărui număr (după cele şase-şapte zerouri), observăm că acelea sunt chiar valorile facturate care ne interesează Prin urmare, nu ne mai rămâne decât să extragem acea parte: SELECT DenCl, CAST ( SUBSTR ( CAST ( SUM ( DISTINCT * LF NrFactt * LF Linie+ Cantitate * PretUnit * ( +ProcTVA) ) AS CHAR( ) ) , , ) AS DECIMAL( , ) ) AS Valoare Facturata FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr = LF CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact INNER JOIN CLIENŢI C ON F CodCl = C CodCl LEFT OUTER JOIN INCASFACT I ON F Nrfact=I NrfACT GROUP BY DenCl Obţinem ceea ce doream, adică valoarea vânzărilor pe clienţi, după cum o arată figura DENCL VALOARE FACTURATA  Clienţi SRL   Client SA   Client SRL   Client   Client SRL   Client SA   Client SRL    în final, soluţia SQL- /DB la problema pusă (şi răspunsul în figura ): SELECT DenCl, CAST (SUBSTR (CAST (SUM ( DISTINCT * LF NrFact+ * LF Linie+ Cantitate * PretUnit * ( +ProcTVA) ) AS CHAR( ) ) , , ) AS DECIMAL( , ) ) AS Valoare Facturata, SUM (CASE WHEN LF Linie > THEN NULL ELSE VALUE(Transa, ) END) AS Valoare Incasata, CAST (SUBSTR (CAST (SUM ( DISTINCT * LF NrFact+ * LF Liniet Cantitate * PretUnit * ( +ProcTVA) ) AS CHAR( ) ) , , ) AS DECIMAL( , ) ) - SUM (CASE WHEN LF Linie > THEN NULL ELSE VALUE(Transa, ) END) AS Rest De Incasat FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr = LF CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact INNER JOIN CLIENŢI C ON F CodCI = C CodCI LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact GROUP BY DenCl HAVING CAST (SUBSTR (CAST (SUM ( DISTINCT * LF NrFact+ * LF Linie+ Cantitate * PretUnit * ( +ProcTVA) ) AS CHAR( ) ) , , ) AS DECIMAL( , ) ) - SUM (CASE WHEN LF Linie > THEN NULL ELSE VALUE(Transa, ) END) >= ALL (SELECT CAST (SUBSTR (CAST (SUM ( DISTINCT * LF NrFact+ * LF Linie+ Cantitate * PretUnit * ( +ProcTVA) ) AS CHAR( ) ) , , ) AS DECIMAL( , ) ) - SUM (CASE WHEN LF Linie > THEN NULL ELSE VALUE(Transa, ) END) FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr = LF CodPr INNER JOIN FACTURI F ON LF NrFact = F NrFact INNER JOIN CLIENŢI C ON F CodCI = C CodCI LEFT OUTER JOIN INCASFACT I ON F NrFact=I NrFact GROUP BY DenCl) DENCL r j VALOARE FACŢURATA ): VALQAREJNCASATA | REST DE IMCASW Client SRL ’ ~~ | Figura Clientul ce are cel mai mare rest de plată (DB ) Varianta Oracle pentru obţinerea aceluiaşi rezultat este: SELECT DenCl, TO NUMBER( SUBSTR ( TO CHAR ( SUM(DISTINCT * LF NrFact+ * LF Linie+Cantitate * PretUnit * ( +ProcTVA)), ' '), , )) AS Valoare Facturata, SUM (DECODE (LF Linie, , NVL(Transa, ), NULL)) AS Incasari, TO NUMBER( SUBSTR ( TO CHAR ( SUM(DISTINCT * LF NrFact+ * LF Linie+Cantitate * PretUnit * ( +ProcTVA)), ' '), , )) -• SUM (DECODE (LF Linie, , NVL(Transa, ), NULL)) AS De Incasat FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C, INCASFACT I WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact AND F CodCl = C CodCl AND F Nrfact= NrFact (+) GROUP BY DenCl HAVING TO NUMBER( SUBSTR ( TO CHAR ( SUM(DISTINCT * LF NrFact+ * LF Linie+Cantitate * PretUnit * ( +ProcTVA)), - '), , )) - SUM (DECODE (LF Linie, , NVL(Transa, ), NULL)) >= ALL (SELECT TO NUMBER( SUBSTR ( TO CHAR ( SUM(DISTINCT * LF NrFact+ * LF Linie+Cantitate * PretUnit * ( +ProcTVA)), ' '), , )) - SUM (DECODE (LF Linie, , NVL(Transa, ), NULL)) FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C, INCASFACT I WHERE P CodPr = LF CodPr AND LF NrFact = F NrFact AND F CodCl = C CodCl AND F Nrfact=I NrFact (+) GROUP BY DenCl) Din nou despre diviziunea relaţională Revenind la cazul teoretic din capitolul (figura ), câtul diviziunii relaţionale a Rl: R (altfel spus, găsirea tuturor „icşilor” care sunt în Rl în combinaţie cu toţi „igrecii” din R ) se calculează în SQL şi astfel: SELECT X FROM Rl GROUP BY X HAVING COUNT(Y) = (SELECT COUNT(Y) FROM R ) Căror clienţi li s-a trimis măcar o factură în toate zilele cu vânzări? SELECT DenCl FROM FACTURI F, CLIENŢI C WHERE F CodCl=C CodCI GROUP BY DenCl HAVING COUNT(DISTINCT DataFact) = (SELECT COUNT (DISTINCT DataFact) FROM FACTURI) Modest ca volum (nu şi ca importanţă), răspunsul se găseşte în figura dencl Client SRL Figura Clientul pentru care există cel puţin o factură în fiecare zi Ce produse au fost vândute tuturor clienţilor? SELECT DenPr FROM PRODUSE P, LINIIFACT LF, FACTURI F WHERE P CodPr=LF CodPr AND LF NrFact=F NrFact GROUP BY DenPr HAVING COUNT(DISTINCT CodCI) = (SELECT COUNT (CodCI) FROM CLIENŢI) Răspunsul este Produs Secvenţializarea interogărilor Cu tot ataşamentul pentru Visual FoxPro, în materie de SQL (şi nu numai) există un decalaj serios faţă de standardul SQL- şi faţă de SGBD-urile profesionale: (IBM) DB , Oracle, Informix, Sybase, (Microsoft) SQL Server etc Aceasta este vestea rea Vestea bună e că mai toate interogările dificile, ce nu pot fi formulate printr-o singură frază SELECT principală (plus subconsultări pe un singur nivel), au leac în VFP salvând rezultatul unei interogări în tabele temporare (cursoare), tabele derivate sau chiar tabele obişnuite care devin „materie primă” pentru alte fraze SELECT ş a m d Prin dispunerea succesivă a interogărilor se redactează programe ( PRG) lansate în execuţie atunci când se doreşte informaţia respectivă sau când se obţine un raport Uneori însă, şi în SGBD-urile din lumea foarte bună este necesară salvarea rezultatelor intermediare în cadrul aceleiaşi interogări sau pentru prelucrări ulterioare De obicei, tabelele derivate constituie un suport universal pentru asemenea gen de operaţiuni Sunt însă şi soluţii mai la îndemână Ceva mai înainte evocam cursoarele VFP în DB , tabelele temporare îmbracă forma expresiilor-tabele care sunt tabele temporare a căror definiţie este păstrată numai pe parcursul „vieţii” interogării în care este inclusă Prin urmare, nu pot fi folosite pentru „pasarea” rezultatelor intermediare între SELECT-uri independente Fraze SELECT independente în VFP Ne vom focaliza atenţia mai întâi pe VFP, pentru că aici avem de recuperat câteva handicapuri: un singur nivel de subconsultare, subconsultări în clauza HAVING şi subconsultări în FROM Să se afişeze, pentru fiecare factură, dacă este fără nici o încasare, încasată parţial sau încasată total (şi cele trei valori: facturată, încasată şi rămasă de încasat)? Am ales pentru început una dintre primele probleme care creează necazuri în VFP în varianta SQL curată, adică neprocedurală Listingul conţine o soluţie mult mai simplă alcătuită din trei fraze SQL independente Primele două obţin cursoarele utilizate în a treia Cursorul este, cel puţin pentru exemplele noastre în VFP, o tabelă temporară: poate fi închisă explicit sau la ieşirea din VFP; la închidere se şterge, deci după utilizare nu mai ocupă spaţiu pe disc Listing Situaţia încasării fiecărei facturi cursorul cVINZARI conţine valoarea fiecărei facturi SELECT NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) ; AS Facturat ; FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr = P CodPr ; INTO CURSOR cVINZARI ; GROUP BY NrFact cINCASARI conţine valoarea incasata pentru fiecare factura SELECT NrFact, SUM(Transa) AS încasat ; FROM INCASFACT ; INTO CURSOR cINCASARI ; GROUP BY NrFact se jonctioneaza (extern) cele doua cursoare SELECT V NrFact, Facturat, NVL(încasat, ) AS încasat, ; Facturat - NVL(încasat, ) AS Diferenţa, ; IIF(Facturat=NVL(încasat, ), 'ÎNCASATA TOTAL ', ; IIF(Facturat > NVL(încasat, ) AND NVL(încasat, ) > , ; 'încasata parţial ', 'Fara nici o incasare')) ; AS Situatiune ; FROM cVINZARI V LEFT OUTER JOIN cINCASARI I ON V NrFact=I NrFact Reproşul principal adus acestei soluţii VFP este proceduraiitatea, în vădită contradicţie cu filosofia SQL — curat neprocedurală, frecând peste supărare, ajungem şi la principalul atu: se oferă, totuşi, răspunsul corect la problema formulată Care sunt clienţii pentru care există cel puţin câte o factură emisă în fiecare zi? Varianta procedurală este prezentată în Iistingul Listing Clienţii pentru care există cel puţin câte o factură emisă în fiecare zi Produsul cartezian al valorilor DenCl si DataFact SELECT DISTINCT DenCl, DataFact ; FROM CLIENŢI, FACTURI ; INTO CPRSOR cPRODUS CARTEZIAN Clienţii si zilele in care s-au emis facturi pentru ei SELECT DISTINCT DenCl, DataFact ; FROM CLIENŢI INNER JOIN FACTURI ON CLIENŢI CodCl=FACTURI CodCI ; INTO CURSOR cRl Valorile DenCl care nu se regăsesc combinate cu toate valorile DataFact SELECT DISTINCT DenCl ; FROM cProdus Cartezian ; INTO CURSOR cNu I ; WHERE DenCl+DTOC(DataFact) NOT IN ; (SELECT DenCl+DTOC(DataFact) ; FROM cRl) in fine, rezultatul SELECT DISTINCT DenCl ; FROM cRl ; WHERE DenCl NOT IN ; (SELECT DenCl ; FROM cNu I) Continuăm cu alte exemple care au fost, până acum, frunstrante pentru fox-işti, cele în care în clauza HAVING apare o subconsultare Care este ziua în care s-au emis cele mai multe facturi? Practic, în prezentul caz, ca şi în celelalte de acest tip, prin cursoare, grupurile sunt transformate în tupluri şi, în loc de HAVING, se va folosi WHERE Listing Ziua (zilele) în care s-au emis cele mai multe facturi? SELECT DataFact, COUNT(*) AS Nr ; FROM FACTURI ; INTO CURSOR cNrFact Zilnic ; GROUP BY DataFact SELECT DataFact, Nr ; FROM cNrFact Zilnic ; WHERE Nr IN ; (SELECT MAX(Nr) ; FROM cNrFact Zilnic) Care este judeţul în care berea s-a vândut cel mai bine? După cum se observă, am selectat numai exemplele de importanţă majoră pentru ţară Răspunsul la această tulburătoare problemă este oferit de programul din listing Listing Judeţul în care berea s-a vândut cel mai bine SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) ; AS Vinzari Bere ; FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, ; LINIIFACT LF, PRODUSE P ; INTO CURSOR cBere ; WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl ; AND F NrFact=LF NrFact AND LF CodPr=P CodPr AND Grupa='Bere' ; GROUP BY Judeţ SELECT Judeţ, Vinzari Bere ; FROM cBere ; WHERE Vinzari Bere >= ALL ; (SELECT DISTINCT Vinzari Bere ; FROM cBere) Care este judeţul cu vânzări imediat superioare judeţului Neamţ? Soluţia din listingul are un dram suplimentar de interes, deoarece la ultima sa interogare, în afara clauzei WHERE care conţine două subconsultări, se efectuează theta-joncţiunea dintre cele două cursoare, cVinzari Neamt şi cVinzari Judete Listing Judeţul cu vânzări imediat peste cele ale judeţului Neamţ , Vinzarile jud Neamţ SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari ; FROM JUDEŢE J ; INNER JOIN LOCALITATI L ON J Jud=L Jud ; INNER JOIN CLIENŢI C ON L CodPost=C CodPost ; INNER JOIN FACTURI F ON C CodCl=F CodCl ; INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact ; INNER JOIN PRODUSE P ON LF CodPr=P CodPr ; INTO CURSOR cVinzari Neamt ; WHERE Judet='Neamţ' Vinzarile fiecărui judeţ SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari ; FROM JUDEŢE J ; INNER JOIN LOCALITATI L ON J Jud=L Jud ; INNER JOIN CLIENŢI C ON L CodPost=C CodPost ; INNER JOIN FACTURI F ON C CodCl=F CodCl ; INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact ; INNER JOIN PRODUSE P ON LF CodPr=P CodPr ; INTO CURSOR cVinzari Judete ; GROUP BY Judeţ SELECT Judeţ, Vinzari ; FROM cVinzari Judete ; WHERE Vinzari cVinzari Neamt Vinzari) ; AND Vinzari > ALL ; (SELECT Vinzari ; FROM cVinzari Neamt) Care este clientul cel mai mare datornic? Este de-a dreptul reconfortant că nu trebuie să mai apelăm la artificiile pentru calculul valorilor facturate şi încasate - vezi listingul Listing Clientul cu cel mai mare rest de plată Valorile facturate, pe clienţi SELECT CodCI, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat ; FROM FACTURI F ; INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact ; INNER JOIN PRODUSE P ON LF CodPr=P CodPr ; INTO CURSOR cFACTURAT ; GROUP BY CodCI Valorile incasate, pe clienţi SELECT CodCI, SUM(Transa) AS încasat ; FROM FACTURI F ; INNER JOIN INCASFACT I ON F NrFact=I NrFact ; INTO CURSOR cINCASAT ; GROUP BY CodCI Restul de plata, pe clienţi SELECT cFACTURAT CodCI, Facturat, NVL(încasat, ) AS încasat, ; Facturat - NVL(Incasat, ) AS De Incasat ; FROM cFACTURAT LEFT OUTER JOIN cINCASAT ; ON cFACTURAT CodCl=cINCASAT CodCI ; INTO CURSOR cDe INCASAT ; Finalul apoteotic SELECT DenCl, cDe INCASAT * ; FROM cDe INCASAT INNER JOIN CLIENŢI ; ON cDe INCASAT CodCl=CLIENTI CodCI ; WHERE De Incasat >= ALL ; (SELECT De Incasat ; FROM cDe INCASAT) Căror clienţi li s-a trimis măcar o factură în toate zilele de vânzare? Nici problemele ce impun soluţii de tip diviziune relaţională nu mai constituie o dificultate urmând logica interogărilor independente - listingul Listing Clientul căruia i s-a trimis măcar o factură în toate zilele de vânzare SELECT CodCI, COUNT(DISTINCT DataFact) AS Cite Zile ; FROM FACTURI ; INTO CURSOR cl ; GROUP BY CodCI SELECT DenCl ; FROM CLIENŢI INNER JOIN cl ON CLIENŢI CodCl=cl CodCI ; WHERE Cite Zile =ANY ; (SELECT COUNT(DISTINCT DataFact) ; FROM FACTURI) Scripturi cu interogări secvenţiale în Oracle şi DB Deşi oarecum stânjenitoare, secvenţializarea interogărilor se poartă şi la case mai mari Una dintre ele - Oracle, iar alta IBM DB Fie că este vorba despre cunoştinţe nu prea avansate de SQL, fie despre o anumită comoditate, cert este că de multe ori interogări insolubile se pot rezolva ceva mai primitiv Care este clientul cu cel mai mare rest de plată? încercăm să facem uitată penibila soluţie formulată în paragraful precent, ce-i drept, înlocuind-o cu o soluţie tot din „lumea a treia” a SQL-ului, deoarece se bazează pe un script în care rezultatele intermediare ale consultărilor se salvează nu în cursoare, ci în tabele derivate Listing Script Oracle de aflare a clientului cu cel mai mare rest de plată Valorile facturate, pe clienţi DROP VIEW vDe Incasat ; DROP VIEW vlncasat ; DROP VIEW vFacturat ; CREATE VIEW vFacturat AS SELECT CodCl, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY CodCl ; Valorile incasate, pe clienţi CREATE VIEW vlncasat AS SELECT CodCl, SUM(Transa) AS încasat FROM FACTURI F, INCASFACT I WHERE F NrFact=I NrFact GROUP BY CodCl ; Restul de plata, pe clienţi CREATE VIEW vDe INCASAT AS SELECT VFACTURAT CodCl, Facturat, NVL(încasat, ) AS încasat, Facturat - NVL(încasat, ) AS De Incasat FROM VFACTURAT, vINCASAT WHERE VFACTURAT CodCl=vINCASAT CodCl (+) ; Finalul SELECT DenCl, vDe INCASAT * FROM vDe INCASAT, CLIENŢI WHERE vDe INCASAT CodCl=CLIENTI CodCl AND De Incasat >= ALL (SELECT De Incasat FROM vDe INCASAT) ; De remarcat că şi în VFP, în loc de cursoare puteam folosi tabele derivate Care sunt primii trei clienţi în ordinea descrescătoare a datoriilor (cei mai mari trei datornici)? Iată o interogare al cărei răspuns ar interesa multă lume, mai ales dacă baza de date ar fi la nivel naţional Cu toate opintelile de care suntem în stare, la acest moment ne este cu neputinţă să răspundem altfel decât printr-un script - listingul Din nefericire, soluţia a fost îngreunată de faptul că nu se poate folosi clauza ORDER BY într-o comandă CREATE VIEW Listing Script Oracle pentru extragerea primilor datornici DROP VIEW vOrdonare ; DROP VIEW vDe Incasat ; DROP VIEW vlncasat ; DROP VIEW vFacturat ; Valorile facturate, pe clienţi CREATE VIEW vFacturat AS SELECT CodCI, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY CodCI WITH READ ONLY; Valorile incasate, pe clienţi CREATE VIEW vlncasat AS SELECT CodCI, SUM(Transa) AS încasat FROM FACTURI F, INCASFACT I WHERE F NrFact=I NrFact GROUP BY CodCI WITH READ ONLY ; Restul de plata, pe clienţi, in ordinea (descrescătoare a) valorii CREATE VIEW vDe INCASAT AS SELECT DenCl, vFACTURAT CodCI, Facturat, NVL(încasat, ) AS încasat, Facturat - NVL(încasat, ) AS De^Incasat FROM VFACTURAT, vINCASAT, CLIENŢI WHERE VFACTURAT CodCl=CLIENTI CodCI AND VFACTURAT CodCl=vINCASAT CodCI (+) WITH READ ONLY ; Primii trei datornici CREATE VIEW vORDONARE AS SELECT * FROM vDe INCASAT WHERE De Incasat >= (SELECT MAX(De Incasat) FROM vDe INCASAT WHERE De Incasat = (SELECT MAX(De Incasat) FROM vDe INCASAT WHERE De încasat = ALL (SELECT Vinzari Bere FROM BERE JUDEŢE) Care este clientul cu cel mai mare rest de plată? Revenim la una dintre cele mai dificile probleme de până acum, de data aceasta cu o soluţie „apetisantă” WITH FACTURAT AS (SELECT CodCl, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY CodCl), ÎNCASAT AS (SELECT CodCl, SUM(Transa) AS încasat FROM FACTURI F, INCASFACT I WHERE F NrFact=I NrFact GROUP BY CodCl) SELECT DenCl, Facturat, VALUE(încasat, ) AS încasat, Facturat - VALUE(încasat, ) AS De Incasat FROM CLIENŢI INNER JOIN FACTURAT ON CLIENŢI CodCl=FACTURAT CodCl LEFT OUTER JOIN ÎNCASAT ON FACTURAT CodCl-'rvCASAT CodCl WHERE Facturat - VALUE(încasat, ) >= ALL (SELECT Facturat - VALUE(încasat, ) FROM FACTURAT LEFT OUTER JOIN ÎNCASAT ON FACTURAT CodCl=INCASAT CodCl) Capitolul SQL ŞI MAI AVANSAT Primul dintre capitolele dedicate frazelor SELECT, , se numeşte Elemente de bază ale interogărilor SQL, iar capitolul - SQL (ceva) mai avansat Cum prezentul capitol a fost intitulat SQL şi mai avansat, în mod normal, dacă şi următorul continua problematica interogărilor, ar fi trebuit să se numescă SQL al naibii de avansat Din fericire, acesta este ultimul în care se discută despre opţiuni de consultare, câteva opţiuni care se încadrează în elementele de fineţe ale limbajului Concret, vor fi abordate: corelarea simplă şi dublă cu şi fară ajutorul operatorului EXISTS, subinterogări în clauza FROM, interogările scalare şi cele ierarhice Interogări corelate Operatorul EXISTS Ca şi IN, operatorul EXISTS permite legarea frazei SELECT principale de una sau mai multe subconsultări şi, astfel, formularea unor interogări complexe Prin EXISTS se defineşte un predicat care are valoarea logică „adevărat” dacă subconsultarea s-a concretizat într-o tabelă ce are cel puţin o linie • în general, EXISTS poate înlocui cu succes operatorul IN Reciproca nefiind valabilă' , unii autori, precum C J Date, îl preferă şi recomandă la formularea subconsultărilor Pe de altă parte însă, EXISTS este unul dintre cei mai dificili operatori Logica sa se deosebeşte radical de cea a lui IN Utilizând operatorul IN, în tabela-rezultat se extrag acele linii din tabela (tabelele) din fraza SELECT principală care satisfac o condiţie aplicată liniilor din subconsultare La utilizarea lui EXISTS se extrag linii tot ale tabelei/tabelelor frazei SELECT principală, dar pe baza existenţei a cel puţin o linie în tabela/tabelele subconsultării, care satisface (satisfac),' pe lângă restricţii proprii, şi condiţii formulate luându-se în considerare atribute/tabele din fraza principală (cam întortocheat, nu-i aşa?) Predicatele din clauza WHERE operează la nivel de linie, şi nu la nivel de ansamblu (seturi de înregistrări), ceea ce, după Joe Celko, este o deviere de la spiritul relaţional Pe de altă parte, Sheryl Larsen pledează pentru folosirea lui EXISTS în detrimentul IN-ului pe considerentul optimizării IN presupune crearea unor tabele temporare ce reclamă uneori timp de execuţie sensibil mai mare prin comparaţie cu logica tuplu-cu-tuplu EXISTS-enţială Pentru comparaţie, începem cu exemple formulate în capitolul precedent la prezentarea operatorului IN Ce facturi au fost emise în aceeaşi zi cu factura ? Varianta de interogare bazată pe operatorul EXISTS se prezintă astfel: SELECT NrFact FROM FACTURI FI WHERE EXISTS (SELECT * FROM FACTURI F WHERE F NrFact= AND FI DataFact=F DataFact) Logica execuţiei se derulează după un scenariu top-bottom-top (sus-jos-sus) prezentat în figura NrFact DataFact CodCI Obs    / /  NULL    / /  Probleme    / /  NULL    / /  NULL    / /  NULL    / /  Preţul    / /  NULL    / /  NULL    / /  NULL    / /  NULL    / /  NULL    / /  NULL   Pas [ / / [NULL ~| Exista in F linii pentru care NrFact= si DataFact= / / ? NI Pas / / iProbleme | Exista in F linii pentru care NrFact- si DataFact= ffl i ? NU I Pas / / |NULL | Exista in F linii pentru care NrFact- si DataFact- / / ? NU! Pas [ / / |NULL Exista in F linii pentru care NrFact- si DataFact- ff> / ? NU I F NrFact DataFact CodCI Obs    / /  NULL    / /  Probleme    / /  NULL    / /  NULL    / /  NULL    / /  Preţul    / /  NULL    / /  NULL    / /  NULL    / /  NULL    / /  NULL    / /  NULL   Pas j / / | NULL | Exista in F linii pentru care NrFact= si DataFact= jD / ? NU I se / / Preţul | Exista in F linii pentru care NrFact- si DataFact- /D / ? NU I Pas / / INULL | Exista in F linii pentru care NrFact- si DataFact- / / ? NU I Pas / / |NULL | Exista in F linii pentru care NrFact- si DataFact- / / ? NU I > | / / ! INULL | Exista in F linii pentru care NrFact- si DataFact- / / ? DA I Pas / / INULL | Exista in F linii pentru care NrFact- si DataFact- / / ? DA! Pas | / / INULL | ' Exista in F linii pentru care NrFact- si DataFact- / / ? DA! Pas | | / / INULL | Exista in F linii pentru care NrFact- si DataFact- / / ? DA I Figura Logica operatorului EXISTS Elementul de dificultate ţine de modalitatea de exprimare a condiţiei, care este una indirectă Se parcurge fiecare linie din SELECT-ul principal, examinându-se, pe rând, dacă există măcar o linie în subconsultare care să satisfacă predicatul subconsultării Dacă da, atunci nu aceasta se inserează în rezultat, ci linia din SELECT-ul principal! Nu ştiu cum e mai nimerit să-i zicem, lucru în echipă sau însuşirea de către SELECT-ul principal a meritelor SELECT-ului „subaltern” Dacă se doreşte eliminarea din rezultat şi a facturii de referinţă, , se modifică uşor interogarea: SELECT NrFact FROM FACTURI' FI WHERE NrFact <> AND EXISTS (SELECT DataFact FROM FACTURI F WHERE F NrFact= AND FI DataFact=F DataFact) Interesant este că interogările corelate pot fi legate nu numai prin operatorul EXISTS, ci şi de IN Altfel spus, interogarea următoare este perfect similară anterioarei: SELECT NrFact FROM FACTURI FI WHERE NrFact <> AND DataFact IN (SELECT DataFact FROM FACTURI F WHERE NrFact= AND FI DataFact=F DataFact) Ce facturi au fost emise în alte zile decât factura ? Următoarele două soluţii conduc la acelaşi rezultat: SELECT NrFact FROM FACTURI FI WHERE NOT EXISTS (SELECT * FROM FACTURI F WHERE F NrFact= AND FI DataFact=F DataFact) sau SELECT NrFact FROM FACTURI FI WHERE EXISTS (SELECT * FROM FACTURI F WHERE F NrFact= AND FI DataFact<>F DataFact) în subconsultarea corelată (cea care succedă operatorului EXISTS), clauza SELECT poate conţine ca argument * sau un atribut care, de preferinţă, nu are valori nule Cea mai simpli sigură şi rapidă (pentru SBGD) variantă este însă folosirea unei constante Spre exemplu, ultim; variantă se poate schimba, aproape insesizabil, în: SELECT NrFact FROM FACTURI FI WHERE EXISTS (SELECT FROM FACTURI F WHERE F NrFact= AND FI DataFactOF DataFact) înlocuirea asteriscului sau a oricărui alt atribut cu nu modifică în nici un fel corectitudinea interogării şi este de bun augur pentru simplitate şi viteza de execuţie Care sunt clienţii cărora li s-au trimis facturi în aceeaşi zi în care a fost întocmită factura ? Soluţie SQL- /DB /Oracle: SELECT DenCl FROM CLIENŢI CI WHERE EXISTS (SELECT FROM FACTURI FI WHERE FI CodCl=Cl CodCl AND EXISTS (SELECT FROM FACTURI F WHERE F NrFact= AND FI DataFact=F DataFact) ) Soluţie VFP: SELECT DenCl ; FROM CLIENŢI C INNER JOIN FACTURI FI ; ON C CodCl=Fl CodCl ; WHERE EXISTS ; (SELECT ; FROM FACTURI F ; WHERE F NrFact= AND FI DataFact=F DataFact) în varianta SQL- /DB /Oracle există două niveluri de subconsultare, însă corelarea este simplă, fiecare „etaj” fiind corelat numai la nivelul imediat superior Peste numai câteva pagini vom discuta câteva aspecte privind dubla corelare In ce judeţe s-a vândut produsul „ Produs "? Formulăm numai soluţia SQL- /DB /Oracle: SELECT Judeţ FROM JUDEŢE J WHERE EXISTS (SELECT FROM LOCALITATI L WHERE L Jud=J Jud AND EXISTS (SELECT FROM CLIENŢI C WHERE C CodPost=L CodPost AND EXISTS (SELECT FROM FACTURI F WHERE F CodCl=C CodCl AND EXISTS (SELECT FROM LINIIFACT LF WHERE LF NrFact=F NrFact AND EXISTS (SELECT FROM PRODUSE P WHERE P CodPr=LF CodPr AND DenPr = 'Produs ' ) ) ) ) ) Această soluţie este una dintre cele mai bune, ca volum de resurse consumat, înlocuind atât costisitoarea joncţiune din interogările de tip INNER JOIN, cât şi numeroasele tabele intermediare presupuse de operatorul IN Nu ne încearcă decât un regret: că nu funcţionează în VFP (din cauza multiplelor niveluri de consultare) Prin EXISTS, fireşte, se poate realiza şi intersecţia a două relaţii Dacă luăm în discuţie relaţiile Rl şi R (capitolul - figura ), intersecţia acestora se realizează şi astfel: SELECT * FROM Rl WHERE EXISTS (SELECT FROM R WHERE Rl A=R C AND Rl B=R D AND R C=R E) La prima vedere, nimic spectaculos La a doua, descoperim că, spre deosebire de soluţia bazată pe IN, această frază funcţionează identic şi în VFP In ce zile s-au vândut şi produsul cu denumirea „ Produs I", şi cel cu denumirea „ Produs ’’? SELECT DISTINCT DataFact FROM PRODUSE PI, LINIIFACT LF , FACTURI FI WHERE PI CodPr = LF CodPr AND LF Nrfact = Fl NrFact AND DenPr = 'Produs ' AND EXISTS (SELECT FROM PRODUSE P , LINIIFACT LF , FACTURI F WHERE P CodPr = LF CodPr AND LF Nrfact = F NrFact AND P DenPr = 'Produs ' AND F DataFact=Fl DataFact) Sunt corelate două instanţe ale joncţiunii PRODUSE-LINIIFACT-FACTURI; prima conţine liniile legate de Produs I, iar a doua de Produs întrucât interesează zilele în care s-au vândut simultan cele două produse, atributul de corelare este Dat a Fact Ce clienţi au cumpărat şi „ Produs ”, şi „ Produs ”, dar nu au cumpărat „ Produs ”? SELECT DISTINCT DenCl FROM PRODUSE, LINIIFACT, FACTURI, CLIENŢI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND FACTURI CodCI = CLIENŢI CodCI AND DenPr = 'Produs ' AND EXISTS (SELECT FROM PRODUSE, LINIIFACT, FACTURI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT NrFact = FACTURI NrFact AND ' DenPr = 'Produs ' AND CodCl=CLIENTI CodCl) AND NOT EXISTS (SELECT FROM PRODUSE, LINIIFACT, FACTURI WHERE PRODUSE CodPr = LINIIFACT CodPr AND LINIIFACT Nrfact = FACTURI NrFact AND DenPr = 'Produs ' AND CodCl=CLIENTI CodCl) Fraza SELECT principală este corelată la două subconsultări dispuse „în linie”, secvenţial S-au folosit şi EXISTS şi NOT EXISTS Nici aceasta nu este o dublă corelare, deoarece avem de-a face cu un singur nivel de subconsultare Care sunt clienţii cărora li s-au întocmit numai două facturi? Este o problemă banală, pentru care se pot formula soluţii interesante Fireşte, cea mai la îndemână variantă este: SELECT DenCl FROM CLIENŢI WHERE CodCl IN (SELECT CodCl FROM FACTURI GROUP BY CodCl HAVING COUNT(NrFact) = ) Şi mai simplă decât aceasta este următoarea: SELECT DenCl FROM CLIENŢI INNER JOIN FACTURI ON CLIENŢI CodCl=FACTURI CodCl GROUP BY DenCl HAVING COUNT(NrFact) = Varianta pe care o consider cea mai interesantă nu foloseşte, pentru corelarea subconsultării cu fraza SELECT principală, nici EXISTS, nici IN: SELECT DenCl FROM CLIENŢI WHERE = (SELECT COUNT(*) FROM FACTURI WHERE FACTURI CodCl=CLIENTI CodCl) Logica interogării: Faza : Se „încarcă” prima linie din CLIENŢI: ( , ‘Client SRL’, ’RlOOl’, ‘Tranziţiei, bis’, ‘ ’, NULL) Se numără, prin funcţia COUNT, câte linii din FACTURI au CodCl = Rezultatul este Se compară din SELECT-ul principal cu rezultatul subconsultării corelate; * , deci ‘CLIENŢI’ nu se include în rezultat  Faza : Se „încarcă” a doua linie din CLIENŢI: ( , ‘Client SA’, ‘R ’, NULL, ‘ ’, ‘ - ’) Se numără, prin funcţia COUNT, câte linii din FACTURI au CodCI = Rezultatul este ^ , deci nici ‘CLIENT ’ nu se include în rezultat Faza : « Se „încarcă” a cincea linie din CLIENŢI: ( , ‘Client SRL’, ‘R ’, NULL, ‘ ’, ‘ - ’) e Se numără, prin funcţia COUNT, câte linii din FACTURI au CodCI = Rezultatul este ® = , iar ‘CLIENT ’ se include în rezultat Din interogările menite să ilustreze folosirea operatorului EXISTS nu puteau lipsi cele legate de diviziunea relaţională Reluăm exemplul simplu ce utilizează relaţiile Rl şi R Pentru a afla valorile lui X aflate în Rl în combinaţie cu toate valorile lui Y din R , se poate recurge şi la soluţia SQL- /DB /Oracle: SELECT DISTINCT X FROM Rl Tl l WHERE EXISTS (SELECT FROM Rl Tl WHERE Tl X = Tl X GROUP BY Tl X HAVING COUNT(DISTINCT T Y) = (SELECT COUNT(Y) FROM R ) ) Se parcurge, pe rând, fiecare linie din Rl De fiecare dată se verifică dacă, pentru X-ul curent, în Rl apar toţi igrecii din R , verificare realizată prin GROUP BY şi HAVING Pe baza acestei soluţii, se poate formula o altă soluţie SQL- /DB /Oracle şi la problema: Extrageţi clienţii pentru care există cel puţin câte o factură emisă în fiecare zi SELECT DISTINCT DenCL FROM CLIENŢI Cl, FACTURI FI WHERE Cl CodCl=Fl CodCI AND EXISTS (SELECT FROM FACTURI F WHERE F CodCI = FI CodCI GROUP BY F CodCI HAVING COUNT(DISTINCT F DataFact) = (SELECT COUNT(DISTINCT DataFact) FROM FACTURI) ) Ultima consultare (de jos), cea din clauza HAVING, calculează numărul total de zile în care sunt vânzări, număr care este Subconsultarea „mijlocie” determină dacă numărul de zile de vânzări pentru clientul curent (CI CodCl) este egal cu (rezultatul subconsultării de jos) Care sunt cele mai mari cinci preţuri unitare la care s-au efectuat vânzări? Această problemă a mai fost formulată în paragraful Revenim cu o soluţie nou-nouţă, bazată pe subinterogări corelate SELECT PretUnit FROM LINIIFACT LF WHERE > (SELECT COUNT(DISTINCT LF PretUnit) FROM LINIIFACT LF WHERE LF PretUnit > LF PretUnit) ORDER BY PretUnit DESC Ideea este grozav de ingenioasă (păcat că nu este a mea): se parcurge linie cu linie prima instanţă a tabelei LINIIFACT - LF Pentru fiecare linie de LF se numără în a doua instanţă a LINIIFACT - LF câte linii prezintă preţul unitar mai mare decât cel de pe linia curentă din LF Dacă numărul calculat prin COUNT (*) este mai mic decât , atunci în rezultat se extrage valoarea LF PretUnit Cum nici eu n-am înţeles prea bine explicaţiile de mai sus, să analizăm interogarea mai pe îndelete Pas : se ia în discuţie primul tuplu din LINIIFACT (LF ) PretUnit are valoarea Se calculează numărul valorilor distincte ale PretUnit din LF pentru care LF PretUnit > LF PretUnit Acest număr este Prin urmare, în LINIIFACT există opt preţuri unitare peste întrucât > , primul tuplu din LF nu este inclus în rezultat Pas : se „încarcă” al doilea tuplu din LINIIFACT (LF ) PretUnit are valoarea Funcţia COUNT din subconsultare întoarce — în LINIIFACT există şase linii cu preţuri unitare peste Cum > , nici al doilea tuplu din LF nu este inclus în rezultat Pas : se „încarcă” al treilea tuplu din LINIIFACT (LF ), în care PretUnit este COUNT întoarce , deci nici al treilea tuplu din LF nu este inclus în rezultat Pas : pe această linie PretUnit este COUNT întoarce ; prin urmare, valoarea va face parte din rezultat în total sunt de paşi, corespunzători tuplurilor din LINIIFACT Păcat că VFP nu suportă asemenea găselniţă, sau cel puţin aşa spune mesajul care ne întâmpină la execuţia acestei interogări Subconsultări dublu corelate Dubla corelare constituie o facilitate bine ocolită de către dezvoltatorii de aplicaţii (eu, unul, am reuşit s-o evit cu brio până în acest paragraf) Sheryl Larsen estima în că mai puţin de % dintre dezvoltatorii de aplicaţii în DB aveau cunoştinţă de interogările dublu corelate Mărturisesc că în articolul lui Sheryl am găsit cea mai bună explicaţie a acestui mecanism în cazul corelării simple, scenariul de execuţie este unul de tip top-bottom-top\ la corelarea dublă lucrurile stau cu mult mai interesant: top-bottom-middle-bottom-middle-top Curat ca lacrima şi explicit ca reforma la români! Dacă n-ar fi fost în joc diviziunea relaţională, n-am fi ajuns aici cu „hermeneutica” SQL Revenim la cele două tabele, Rl şi R , pe care le-am folosit în capitolul la prezentarea diviziunii relaţionale Valorile lui X care se găsesc în Rl în combinaţie cu toate valorile lui Y din R pot fi aflate şi prin interogarea următoare: SELECT DISTINCT X FROM Rl Tl l WHERE NOT EXISTS (SELECT FROM R WHERE NOT EXISTS (SELECT FROM Rl Tl WHERE Tl X=T X AND T Y=T Y ) ) Execuţia frazei SQL se derulează astfel: Faza : Pas : se „încarcă” primul tuplu din Tl l: (xl, yl) şi primul tuplu dinR : yl Pas : se testează dacă există în Tl o linie în care X=xl (Tl l X) şi Y=yl (R Y) Există!, astfel încât se trece la următoarea linie din R Pas : se testează dacă există în Tl o linie în care X=xl (Tl l X) şi Y=y (R Y) Există!, deci se „avansează” încă o linie în R Pas : se testează dacă există în Tl o linie în care X=xl (Tl l X) şi Y=y (R Y) Există!, deci se „avansează” încă o linie în R Pas : se testează dacă există în Tl o linie în care X=xl (Tl l X) şi Y=y (R Y) Există!, deci se „avansează” încă o linie în R Pas : se testează dacă există în Tl o linie în care X=xl (Tl l X) şi Y=y (R Y) Există!, deci se încearcă încărcarea următoarei linii din R Pas : întrucât am ajuns la sfârşitul tabelei R şi toate valorile din R s-au regăsit în Tl în combinaţie cu xl, Pas : subconsultarea de jos (bottom) întoarce TRUE către subconsultarea din mijloc (middle) Subconsultarea din mijloc recepţionează rezultatul SELECT-ului de jos şi îl pasează cu aceeaşi valoare logică sau cu valoare schimbată (dacă apare NOT) interogării principale în această situaţie, SELECT-ul mijlociu primeşte de la cel de jos valoarea logică TRUE, însă, deoarece operatorul de conexiune mijloc-jos este NOT EXISTS, va întoarce SELECT-ului principal FALSE Pas : fraza SELECT principală recepţionează valoarea logică FALSE de la subconsultarea mijlocie Dar operatorul de conexiune sus-mijloc este NOT EXISTS, iar FALSE-ul este transformat în TRUE, iar valoarea xl va fi inclusă în rezultat! Faza : Pas : se „încarcă” al doilea tuplu din TI : (x , yl) şi primul tuplu din R : yl Pas : se testează dacă există în Tl o linie în care X=x (Tl l X) şi Y=yl (R Y) Există!, astfel încât se trece la următoarea linie din R Pas : se testează dacă există în Tl o linie în care X=x (Tl l X) şi Y=y (R Y) Nu există!, iar încărcarea celorlalte linii din R este abandonată şi Pas : subconsultarea de jos (bottom) întoarce FALSE către subconsultarea din mijloc (imiddle) SELECT-ul mijlociu recepţionează valoarea logică FALSE şi, datorită operatorului NOT EXISTS, „pasează” SELECT-ului principal TRUE Pas : fraza SELECT principală recepţionează valoarea logică TRUE de la subconsultarea mijlocie, pe care, la rândul său, o transformă în FALSE, iar valoarea x nu va fi inclusă în rezultat! Lucrurile se continuă cu încă faze, una pentru fiecare linie din Rl Clauza DISTINCT asigură preluarea în rezultat a fiecărei valori o singură dată Dacă privim mai îndeaproape fraza SELECT, observăm că, de fapt, aceasta răspunde la întrebarea: pentru care dintre valorile lui X nu există nici un Y care să nu apară cu X-ul respectiv în combinaţie, pe (măcar) o linie în Rl In ce zile s-au vândut şi produsul cu denumirea „ Produs ”, şi cel cu denumirea „ Produs ”? Soluţia SQL- /DB /Oracle bazată pe corelare dublă este probabil cea mai complicată, mult prea complicată pentru aşa o bagatelă de problemă: SELECT DISTINCT DataFact FROM FACTURI FI, LINIIFACT LF , PRODUSE PI WHERE Fl NrFact = LF NrFact AND LF CodPr=Pl CodPr AND NOT EXISTS (SELECT FROM PRODUSE PI WHERE DenPr IN ('Produs ', 'Produs ') AND NOT EXISTS (SELECT FROM FACTURI F , LINIIFACT LF , PRODUSE P WHERE F NrFact = LF NrFact AND LF CodPr=P CodPr AND F DataFact=Fl DataFact AND P CodPr=Pl CodPr ) ) Extrageţi clienţii pentru care există cel puţin câte o factură emisă în fiecare zi Reluăm această problemă de la diviziunea relaţională ce poate fi rezolvată şi prin SELECT-ul următor: SELECT DISTINCT DenCl FROM CLIENŢI CI, FACTURI FI WHERE CI CodCl=Fl CodCl AND NOT EXISTS (SELECT FROM FACTURI F WHERE NOT EXISTS (SELECT FROM CLIENŢI C , FACTURI F WHERE C CodCl=F CodCI AND C CodCl=Cl CodCI AND F DataFact = F DataFact ) ) Toate soluţiile ce întrebuinţează dubla corelare de până acum au o concurenţă care le pune în umbră Variantele ne-bazate pe dubla corelare sunt mai simple, atât ca dimensiune, cât şi ca mod de înţelegere Este timpul să scoatem din mânecă o problemă de diviziune relaţională care să demonstreze adevărata forţă a dublei corelări şi să justifice generosul efort intelectual pentru a o înţelege: Ce facturi conţin măcar produsele din factura ? SELECT DISTINCT NrFact FROM LINIIFACT LF WHERE NOT EXISTS (SELECT FROM LINIIFACT LF WHERE NrFact = AND NOT EXISTS (SELECT FROM LINIIFACT LF , WHERE LF CodPr = LF CodPr AND LF NrFact=LFl NrFact ) ) LINIIFACT are de linii, deci execuţia se desfăşoară în de faze, dintre care prezentăm două: Faza : Pas : se „încarcă” primul tuplu din LF : ( , , , , ) şi primul tuplu din LF care îndeplineşte condiţia NrFact = : ( , , , , ) Pas : se testează dacă există în LF măcar o linie în care NrFact=llll (LF Nrfact) şi CodPr= (LF CodPr) Există (a doua), astfel încât se trece la următoarea linie din LF care îndeplineşte condiţia NrFact = : ( , , , , ) Pas : se testează dacă există în LF măcar o linie în care NrFact=llll (LF Nrfact) şi CodPr= (LF CodPr) Nu există!, iar Pas : subconsultarea de jos (bottom) întoarce FALSE către subconsultarea din mijloc (middle) SELECT-ul mijlociu recepţionează valoarea logică FALSE şi, datorită operatorului NOT EXISTS, „pasează” SELECT-ului principal TRUE ® Pas : fraza SELECT principală recepţionează valoarea logică TRUE de la subconsultarea mijlocie, pe care, la rândul său, o transformă în FALSE, iar valoarea nu va fi inclusă în rezultat! Faza : Pas : se „încarcă” tuplul din LF : ( ! , , , , ) şi primul tupiu din LF care îndeplineşte condiţia Nr Fact = : ( , , , , ) ® Pas : se testează dacă există în LF măcar o linie în care NrFact= (LF Nrfact) şi CodPr= (LF CodPr) Există (tuplul ), astfel încât se trece la următoarea linie din LF care îndeplineşte condiţia NrFact = : ( , I, , , ) ® Pas : se testează dacă există în LF măcar o linie în care NrFact= (LF Nrfact) şi CodPr= (LF CodPr) Există (tuplul ), astfel încât se încearcă trecerea la următoarea linie din LF care îndeplineşte condiţia NrFact = Cum nu mai există nici o asemenea linie, Pas : subconsultarea de jos (bottom) întoarce TRUE către subconsultarea din mijloc (middle), care, la rândul său, întoarce FALSE SELECT-uiui principal ® Pas : fraza SELECT principală recepţionează valoarea logică FALSE de la subconsultarea mijlocie, prin negarea căreia obţine TRUE, iar valoarea va fi inclusă în rezultat! Fraza SELECT analizată răspunde, de fapt, la întrebarea: Pentru care facturi nu există nici un produs ce apare în factura , dar nu este prezent în factura respectivă? Fără dubla corelare, pot fi formulate şi soluţii bazate pe MINUS (EXCEPT) şi IN, precum: SELECT NrFact FROM LINIIFACT MINUS SELECT DISTINCT LF NrFact FROM LINIIFACT LF , LINIIFACT LF WHERE LF NrFact = AND (LF Nrfact, LF CodPr) NOT IN (SELECT NrFact, CodPr FROM LINIIFACT) (soluţie Oracle; în DB se înlocuieşte MINUS cu EXCEPT) sau cu aceeaşi logică, dar ce utilizează tandemul MINUS (EXCEPT) - EXISTS: SELECT NrFact FROM LINIIFACT MINUS SELECT DISTINCT LFl NrFact FROM LINIIFACT LF , LINIIFACT LF WHERE LF NrFact = AND NOT EXISTS (SELECT FROM LINIIFACT LF WHERE LF NrFact=LFl NrFact AND LF CodPr=LF CodPr) Deşi ultimele două soluţii sunt comparabile, ca dimensiune, cu varianta bazată pe dubla corelare, faptul că logica lor presumme produsul cartezian a două instanţe ale tabelei LINIIFACT tabelă care, în timp, acumulează un uriaş număr de înregistrări, le pune în umbră intru a respecta adevărul istoric, trebuie spus câ se poate recurge la artificii non-diviziune relaţională, precum cel următor: SELECT DISTINCT NrFact FROM LINIIFACT WHERE CodPr IN (SELECT CodPr FROM LINIIFACT WHERE NrFact = ) GROUP BY NrFact HAVING COUNT(*) = (SELECT COUNT(CodPr) FROM LINIIFACT WHERE NrFact = ) Care sunt clienţii cărora li s-au vândut cel puţin produsele vândute clientului CLIENT ? SELECT DenCl FROM CLIENŢI Cl WHERE NOT EXISTS (SELECT FROM CLIENŢI C , FACTURI F , LINIIFACT LF WHERE F NrFact=LF NrFact AND C CodCl=F CodCI AND DenCl='Client ' AND NOT EXISTS (SELECT FROM FACTURI F , LINIIFACT LF WHERE F NrFact=LF NrFact AND Cl CodCl=F CodCI AND LF CodPr=LF CodPr)) Analizând enunţul problemei „Care sunt clienţii rezultă că atributul pentru corelarea consultării principale {top) şi celei de jos (bottom) este CodCI, iar din partea condiţională a enunţului cel puţin produsele ” pentru corelarea mijloc (middle) - jos (bottom) se utilizează atributul CodPr Subconsultări în clauza FROM Posibilitatea de a defini tabele ad-hoc, în clauza FROM, este un privilegiu pe care şi-l pot permite numai SGBD-urile profesionale, serverele de baze de date Ne despărţim, aşadar, din nou de VFP pentru o vreme Care sunt valorile facturate şi încasate, precum şi situaţia („fără nici o încasare ”, „ încasată parţial" sau „ încasată total”) pentru fiecare factură? Soluţia SQL- /DB : SELECT VINZARI Nrfact, Facturat, VALUE(încasat, ) AS încasat, Facturat - VALUE(încasat, ) AS Diferenţa, CASE WHEN VALUE(încasat, ) = THEN 'Fara nici o incasare' WHEN Facturat > VALUE(încasat, ) THEN 'încasata parţial' ELSE 'ÎNCASATA TOTAL' END AS Situatiune FROM (SELECT NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr = P CodPr GROUP BY NrFact) VINZARI LEFT OUTER JOIN (SELECT NrFact, SUM(Transa) AS încasat FROM INCASFACT GROUP BY NrFact) INCASARI ON VINZARI NrFact = INCASARI NrFact Soluţia Oracle : SELECT VINZARI Nrfact, Facturat, NVL(încasat, ) as încasat, Facturat - NVL(încasat, ) as Diferenţa, DECODE (SIGN(Facturat-NVL(încasat, )) , , 'ÎNCASATA TOTAL', - ,'încasat mai mult decit facturat !!!', DECODE(NVL(încasat, ), , 'Fara nici o incasare', 'încasata parţial') ) AS Situatiune FROM (SELECT NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr = P CodPr GROUP BY NrFact) VINZARI, (SELECT NrFact, SUM(Transa) AS încasat FROM INCASFACT GROUP BY NrFact) INCASARI WHERE VINZARI NrFact = INCASARI NrFact (+) în clauza FROM a frazei SELECT principale au fost definite două tabele în toată regula, VÂNZĂRIşi ÎNCASĂRI - vezi figura Prima conţine valoarea totală a fiecărei facturi, în timp ce a doua conţine valoarea încasată Aceste două tabele sunt joncţionate extern după atributul Nr Fact În Oracle , în locul structurii CASE s-a folosit funcţia DECODE Figura Rezultatele celor două subconsultări din clauza FROM Cele două variante nu sunt echivalente Soluţia Oracle afişează, în plus, şi situaţia, oarecum anormală, când valoarea încasată a unei unei facturi o depăşeşte pe cea facturată Să se obţină sporurile de noapte pentru al doilea trimestru al anului , atât lunar, cât şi cumulai Soluţia SQL- /DB : SELECT SL Marca, NumePren, VALUE(SL SporNoapte, ) AS Spor Noapte Aprilie, VALUE(SL SporNoapte, ) AS Spor Noapte Mai, VALUE(SL SporNoapte, ) AS Spor Noapte Iunie, VALUE(SL SporNoapte, ) + VALUE(SL SporNoapte, )+ VALUE(SL SporNoapte, ) AS Spor Noapte Trim II FROM (SELECT PERSONAL Marca, NumePren, SporNoapte FROM PERSONAL LEFT OUTER JOIN SPORURI ON PERSONAL Marca=SPORURI Marca AND An= AND Luna = ) SL INNER JOIN (SELECT PERSONAL Marca, SporNoapte FROM PERSONAL LEFT OUTER JOIN SPORURI ON PERSONAL Marca=SPORURI Marca AND An= AND Luna = ) SL ON SL Marca=SL Marca INNER JOIN (SELECT PERSONAL Marca, SporNoapte FROM PERSONAL LEFT OUTER JOIN SPORURI ON PERSONAL Marca=SPORURI Marca AND An= AND Luna = ) SL ON SL Marca=SL Marca ORDER BY NumePren ® Soluţia Oracle : SELECT SLl Marca, NumePren, NVL(SLl SporNoapte, ) AS Spor Noapte Aprilie, NVL(SL SporNoapte, ) AS Spor Noapte Mai, NVL(SL SporNoapte, ) AS Spor Noapte Iunie, NVL(SLl SporNoapte, ) + NVL(SL SporNoapte, )+ NVL (SL SporNoapte, ) AS Spor Noapte Trim II FROM (SELECT PERSONAL Marca, NumePren, SporNoapte FROM PERSONAL , SPORURI WHERE PERSONAL Marca=SPORURI Marca (+) AND An (+) = AND Luna (+)= ) SLl, (SELECT PERSONAL Marca, SporNoapte FROM PERSONAL , SPORURI WHERE PERSONAL Marca=SPORURI Marca (+) AND An (+) = AND Luna (+)= ) SL , (SELECT PERSONAL Marca, SporNoapte FROM PERSONAL , SPORURI WHERE PERSONAL Marca=SPORURI Marca (+) AND An (+) = AND Luna (+) = ) SL WHERE SLl Marca=SL Marca AND SLl Marca=SL Marca ORDER BY NumePren Clauza FROM principală „calculează” trei tabele ce conţin sporurile de noapte ale lunilor aprilie (SLl), mai (SL ) şi iunie (SL ) ale fiecărui angajat (indiferent de data angajării acestuia) - figura Cele trei tabele sunt joncţionate după atributul Marca Revenim la diviziunea relaţională Succesiunea de paşi prezentată în figura se poate realiza şi prin soluţia SQL- /DB : SELECT DISTINCT X FROM Rl WHERE X NOT IN (SELECT DISTINCT PROD CART X ' FROM (SELECT DISTINCT Rl X, R Y FROM R ,R ) PROD CART LEFT OUTER JOIN Rl ON PROD CART X=R X AND PROD CART Y=R Y WHERE Rl X IS NULL) SL SL SL şi SQL- /DB plus Oracle: SELECT DISTINCT X FROM Rl WHERE X NOT IN (SELECT DISTINCT PROD CART X FROM (SELECT DISTINCT Rl X, R Y FROM R ,R ) PROD CART, Rl WHERE PROD CART X=R X (+) AND PROD CART Y=R Y (+) AND Rl X IS NULL) Putem încerca însă şi ceva mai elegant Ce ziceţi de soluţia: SELECT DISTINCT X FROM ' (SELECT X, COUNT(Y) AS Nr FROM Rl GROUP BY X) TEMP , (SELECT COUNT(Y) AS Nr FROM R ) TEMP WHERE TEMP Nr=TEMP Nr Prima tabelă, TEMP , conţine numărul valorilor lui Y pentru fiecare X din Rl, iar a doua, TEMP , numai numărul total al valorilor lui Y din R - figura TEMP TEMP NR  X   x   x   x   xS    Figura Tabelele intermediare (ad-hoc) TEMP şi TEMP Care sunt clienţii pentru care există cel puţin câte o factură emisă în fiecare zi? Este exemplul din algebra relaţională (figura ), formulat pentru ilustrarea operatorulu: diviziune Soluţia - DB (şi Oracle, operând modificările în sintaxa joncţiunii externe): SELECT DISTINCT DenCl FROM CLIENŢI WHERE CodCI NOT IN (SELECT DISTINCT PROD CART CodCI FROM (SELECT DISTINCT CLIENŢI CodCI, FACTURI DataFact FROM CLIENŢI, FACTURI) PROD CART LEFT OUTER JOIN FACTURI ON PROD CART CodCl=FACTURI CodCI AND PROD CART DataFact=FACTURI DataFact WHERE FACTURI CodCI IS NULL) Soluţia (cea preferată) - DB şi Oracle: SELECT DISTINCT DenCl FROM (SELECT CodCl, COUNT(DISTINCT DataFact) AS Nr FROM FACTURI GROUP BY CodCl) TEMP , (SELECT COUNT(DISTINCT DataFact) AS Nr FROM FACTURI) TEMP , CLIENŢI WHERE TEMP Nr=TEMP Nr AND TEMP CodCl=CLIENTI CodCl In ce zile s-au vândut şi produsul cu denumirea,, Produs I ”, şi cel cu denumirea,, Produs ’’? Este (tot) exemplul din capitolul Soluţia -DB (şi Oracle, înlocuind LEFT OUTER JOIN): SELECT DISTINCT DataFact FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr AND DenPr IN ('Produs ', 'Produs ') AND DataFact NOT IN (SELECT DISTINCT PROD CART DataFact FROM (SELECT DISTINCT DataFact, CodPr FROM FACTURI, PRODUSE WHERE DenPr IN ('Produs ', 'Produs ') ) PROD CART LEFT OUTER JOIN (SELECT F DataFact, LF CodPr FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr ) TEMP ON PROD CART DataFact=TEMPl DataFact AND PROD CART CodPr=TEMPl CodPr WHERE TEMP DataFact IS NULL) Soluţia - DB /Oracle: SELECT DISTINCT DataFact FROM (SELECT F DataFact, COUNT(DISTINCT LF CodPr) AS Nr FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr AND DenPr IN ('Produs ', 'Produs ') GROUP BY F DataFact) TEMP WHERE Nr = Din nou, soluţia a doua contrastează evident, prin simplitate, cu prima Tabela TEMP conţine, pentru fiecare dată calendaristică, numărul de produse, dintre Produs şi Produs ( sau ) care au fost vândute în ziua respectivă Ce facturi conţin măcar produsele din factura ? SELECT DISTINCT NrFact FROM (SELECT NrFact, COUNT(*) AS NrProd FROM LINIIFACT WHERE CodPr IN (SELECT CodPr FROM LINIIFACT WHERE NrFact = ) GROUP BY NrFact ) Tl, (SELECT COUNT(CodPr) AS NrP FROM LINIIFACT WHERE NrFact = ) T WHERE Tl NrProd = T NrP T conţine numărul produselor din factura Tl conţine, pentru fiecare factură, câte produs; sunt comune acesteia şi facturii Prin joncţiunea Tl cu T prin condiţia Tl NrProd = T NrP , se extrag acele linii din Tl care au acelaşi număr de produse prezente în factin ca şi aceasta Care sunt clienţii cărora li s-au vândut cel puţin produsele vândute clientului CLIENT ? SELECT DISTINCT DenCl FROM ( SELECT DenCl, COUNT(*) AS NrProd FROM CLIENŢI C, FACTURI F, LINIIFACT LF WHERE C CodCl=F CodCI AND F NrFact=LF Nrfact AND CodPr IN (SELECT CodPr FROM CLIENŢI C, FACTURI F, LINIIFACT LF WHERE C CodCl=F CodCI AND F NrFact=LF Nrfact AND DenCl='Client ' ) GROUP BY DenCl ) Tl, ( SELECT COUNT(CodPr) AS NrProd FROM CLIENŢI C, FACTURI F, LINIIFACT LF WHERE C CodCl=F CodCI AND F NrFact=LF Nrfact AND DenCl='Client ' ) T WHERE Tl NrProd = T NrProd Logica soluţiei este cât se poate se asemănătoare precedentei, doar că T conţine numl-J produselor vândute' clientului , iar în Tl, pe fiecare linie se găseşte un client şi numSnd produselor vândute clientului care i-au fost vândute şi lui Să se afişeze câte facturi sunt: neîncasate deloc, încasate parţial şi încasate total? Prezentăm numai soluţia DB SELECT CASE WHEN VALUE(încasat, ) = THEN 'Fara nici o incasare' WHEN Facturat > VALUE(încasat, ) THEN 'încasata parţial' ELSE 'ÎNCASATA TOTAL' END AS Situatiune, COUNT (*) AS Nr FROM ( SELECT NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Facturat FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr = P CodPr GROUP BY NrFact ) VINZARI LEFT OUTER JOIN ( SELECT NrFact, SUM(Transa) AS încasat FROM INCASFACT GROUP BY NrFact ) INCASARI ON VINZARI NrFact = INCASARI NrFact GROUP BY CASE WHEN VALUE(încasat, ) = THEN 'Fara nici o incasare' WHEN Facturat > VALUE(încasat, ) THEN 'încasata parţial' ELSE 'ÎNCASATA TOTAL' END Joncţiunea externă la stânga dintre VÂNZĂRI şi ÎNCASĂRI este completată de o structură alternativă multiplă - CASE sau DECODE (în Oracle) Care angajaţi au salariul tarifar egal cu cel al ANGAJAT ? SELECT NumePren FROM (SELECT NumePren, SalTarifar FROM PERSONAL ) TEMP , (SELECT Saltarifar FROM PERSONAL WHERE NumePren='ANGAJAT ') TEMP WHERE TEMP SalTarifar = TEMP SalTarifar Care este ziua în care s-au emis cele mai multe facturi? Din păcate (sau din fericire!), interogarea: SELECT TEMP DataFact, TEMPl Nr FROM (SELECT DataFact, COUNT(Nrfact) AS Nr FROM FACTURI GROUP BY DataFact) TEMP , (SELECT DataFact, COUNT(Nrfact) AS Nr FROM FACTURI GROUP BY DataFact) TEMP WHERE TEMPl Nr >= ALL (SELECT Nr FROM'TEMP ) nu este operaţională Aceasta înseamnă că o tabelă definită ad-hoc într-o frază SELECT nu este recunoscută în subconsultări Se poate, totuşi, utiliza varianta: SELECT DataFact, COUNT(*) AS Nr Facturi FROM FACTURI GROUP BY DataFact HAVING COUNT(*) = (SELECT MAX(Nr) FROM (SELECT DataFact, COUNT(NrFact) AS Nr FROM FACTURI GROUP BY DataFact) TEMP ) în subconsultare s-a definit tabela intermediară TEMP , al cărei atribut Nr este folosit în funcţia MAX din clauza SELECT O altă variantă bazată pe subconsultare în FROM este şi: SELECT DataFact, NrFacturi FROM (SELECT DataFact, COUNT(*) AS NrFacturi FROM FACTURI GROUP BY DataFact) FACT ZILE, (SELECT MAX(COUNT(*)) AS NrMax FROM FACTURI GROUP BY DataFact) MAX WHERE NrFacturi=NrMax Care este clientul care a cumpărat cele mai multe produse? După modelul interogării anterioare, formulăm două soluţii generale (SQL/DB /Oracle) bazate pe subconsultări în clauza FROM Soluţia : SELECT DenCl, COUNT(DISTINCT CodPr) AS Nr Produse FROM CLIENŢI, FACTURI, LINIIFACT WHERE CLIENŢI CodCl=FACTURI CodCI AND FACTURI NrFact=LINIIFACT NrFact GROUP BY DenCl  HAVING COUNT(DISTINCT CodPr) = (SELECT MAX(Nr) FROM (SELECT CodCl, COUNT(DISTINCT CodPr) AS Nr FROM FACTURI, LINIIFACT WHERE FACTURI NrFact=LINIIFACT NrFact GROUP BY CodCl ) TEMP ) ® Soluţia : SELECT DenCl, CL PROD NrProd FROM (SELECT DenCl, COUNT(DISTINCT CodPr) AS NrProd FROM CLIENŢI, FACTURI, LINIIFACT WHERE CLIENŢI CodCl=FACTURI CodCl AND FACTURI NrFact=LINIIFACT NrFact GROUP BY DenCl ) CL PROD, (SELECT MAX(COUNT(DISTINCT CodPr)) AS NrProd FROM FACTURI, LINIIFACT WHERE FACTURI NrFact=LINIIFACT NrFact GROUP BY CodCl) CL MAX WHERE CL PROD NrProd=CL MAX NrProd Care este judeţul în care berea s-a vândut cel mai bine? SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari Bere FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr AND Grupa='Bere' GROUP BY Judeţ HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) = (SELECT MAX(Vinzari) FROM (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr AND Grupa='Bere' GROUP BY Jud ) TEMP ) Care sunt clienţii cu valoarea vânzărilor peste medie? Soluţia : SELECT DenCl, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE C CodCl=F CodCI AND F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY DenCl HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) >= (SELECT Vinzari / NrClienti FROM (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr ) TEMP , (SELECT COUNT(DISTINCT CodCI) AS NrClienti FROM FACTURI) TEMP ) ® Soluţia : SELECT DenCl, VINZ CL Vinzari FROM (SELECT DenCl, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE C CodCl=F CodCI AND F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY DenCl ) VINZ CL, (SELECT DISTINCT Vinzari / NrClienti AS Medie Vinz FROM (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr), (SELECT COUNT(DISTINCT CodCI) AS NrClienti FROM FACTURI) ) MEDIE VINZ WHERE VINZ CL Vinzari >= MEDIE VINZ Medie Vinz Care este factura cu cea mai mică valoare peste cea medie? SELECT NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS ValFact FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr GROUP BY NrFact  HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) = (SELECT MIN(ValFact) FROM (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) AS ValFact FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr GROUP BY NrFact) TEMP WHERE ValFact > (SELECT Vinzari / NrFacturi AS ValMedie FROM (SELECT SUM(Cantitate * PretUnit * ( + ProcTVA)) AS Vinzari, COUNT(DISTINCT NrFact) AS NrFacturi FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr ) TEMP ) ) Apelăm şi la o soluţie care să afişeze toate facturile cu valoarea peste medie, în ordinea crescătoare a acestei valori Prima factură din rezultat - figura - va fi răspunsul la întrebarea formulată SELECT NrFact, ValFact, ValMedie FROM (SELECt NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS ValFact FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr GROUP BY NrFact) TEMP , (SELECT ROUND(Vinzari / NrFacturi, ) AS ValMedie FROM (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari, COUNT(DISTINCT NrFact) AS NrFacturi FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr) MEDIEI ) MEDII WHERE ValFact > ValMedie ORDER BY ValFact NRFACT VALFACT VALMEDIE              Care este judeţul cu vânzări imediat superioare judeţului Neamţ? Soluţia precedentă este rezonabilă, dar nu răspunde punctual la întrebare Drept care, la prezentul exemplu, ne punem problema afişării numai a judeţului şi valorii vânzărilor Vom apela la un truc ieftin, pe care l-am mai utilizat Iată interogarea DB şi rezultatul său în figura SELECT MIN (CAST (CAST (VINZ JUD Vinzari AS DECIMAL ( , )) AS CHAR ( )) CONCAT ' - ' CONCAT VINZ JUD Judeţ) AS Rezultat FROM (SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCI AND F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY Judeţ) VINZ JUD , (SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCI AND F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY Judeţ) VINZ JUD WHERE VINZ JUD Vinzari > VINZ JUD Vinzari AND VINZ JUD Judet='Neamţ'  Figura Judeţul cu vânzări imediat superioare judeţului Neamţ Tabelele ad-hoc VINZJUD şi VINZ JUD sunt identice şi conţin valoarea vânzărilor pentru fiecare judeţ Fraza SELECT principală le theta-joncţionează, după expresia VINZ JUD Vinzari > VINZ JUD Vinzari, în condiţiile în care această comparaţie se face pentru linia în care VINZ JUD Judet= ' Neamţ' Rezultă că vor fi extrase acele judeţe (şi vânzările corespunzătoare) care au valoarea vânzărilor peste cea a judeţului Neamţ Trucul ieftin de care vorbeam este plasat în clauza SELECT a interogării principale Ideea este de a concatena valoarea vânzărilor cu denumirea judeţului Cum minimul este decis de primul argument, cârpeala funcţionează! O soluţie fără improvizaţii este următoarea: SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY Judeţ HAVING SUM(Cantitate * PretUnit * ( +ProcTVA)) = (SELECT MIN ( VINZ JUDI Vinzari) FROM (SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY Judeţ) VINZ JUD , (SELECT Judeţ, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM JUDEŢE J, LOCALITATI L, CLIENŢI C, FACTURI F, LINIIFACT LF, PRODUSE P WHERE J Jud=L Jud AND L CodPost=C CodPost AND C CodCl=F CodCl AND F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY Judeţ) VINZ JUD WHERE VINZ JUD Vinzari > VINZ JUD Vinzari AND VINZ JUD Judet= Neamţ') Prima variantă furnizează un răspuns incomplet dacă sunt la egalitate două sau mai multe judeţe care îndeplinesc condiţia Care este clientul cel mai datornic (care are cel mai mare rest de plată)? Fondul problemei este asemănător celei precedente în interogare obţinem o tabelă ad-hoc cu diferenţa de încasat pe clienţi (TEMP ) şi o alta ce conţine cea mai mare diferenţă de încasat pentru un client (TEMP ) Cele două tabele sunt joncţionate după diferenţă şi, în final, pentru a afla denumirea clientului, adăugăm injoncţiune tabela CLIENŢI Soluţia DB : SELECT DenCl, Vinzari, Incasari, Delncasat FROM (SELECT FACTURAT CodCl, Vinzari, VALUE(Incasari, ) AS Incasari, Vinzari - VALUE(Incasari, ) AS Delncasat FROM (SELECT CodCl, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY CodCl) FACTURAT LEFT OUTER JOIN '(SELECT CodCI, SUM(Transa) AS Incasari FROM FACTURI F, INCASFACT I WHERE I NrFact=F NrFact GROUP BY CodCI) ÎNCASAT ON FACTURAT CodCl=INCASAT CodCI ) TEMP INNER JOIN (SELECT MAX (Vinzari - VALUE(Incasari, )) AS DifMax FROM (SELECT CodCI, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY CodCI) FACTURAT LEFT OUTER JOIN (SELECT CodCI, SUM(Transa) AS Incasari FROM FACTURI F, INCASFACT I WHERE I NrFact=F NrFact GROUP BY CodCI) ÎNCASAT ON FACTURAT CodCl=INCASAT CodCI) TEMP ON TEMP DeIncasat=TEMP DifMax INNER JOIN CLIENŢI ON TEMP CodCl=CLIENTI CodCI şi Oracle: SELECT DenCl, Vinzari, Incasari, Delncasat FROM CLIENŢI, (SELECT FACTURAT CodCI, Vinzari, NVL(Incasari, ) AS Incasari, Vinzari - NVL(Incasari, ) AS Delncasat FROM (SELECT CodCI, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY CodCI) FACTURAT, (SELECT CodCI, SUM(Transa) AS Incasari FROM FACTURI F, INCASFACT I WHERE I NrFact=F NrFact GROUP BY CodCI) ÎNCASAT WHERE FACTURAT CodCl-INCASAT CodCI (+) ) TEMP , (SELECT MAX (Vinzari - NVL(Incasari, )) AS DifMax FROM (SELECT CodCI, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact=LF NrFact AND LF CodPr=P CodPr GROUP BY CodCl) FACTURAT, (SELECT CodCl, SUM(Transa) AS Incasari FROM FACTURI F, INCASFACT I WHERE I NrFact=F NrFact GROUP BY CodCl) ÎNCASAT WHERE FACTURAT CodCl=INCASAT CodCl (+) ) TEMP WHERE TEMP DeIncasat=TEMP DifMax AND TEMP CodCl=CLIENTI CodCl Subconsultări scalare în clauza SELECT Standardul SQL- face trimitere şi la interogările scalare ce pot fi definite ca fraze SELECT ce obţin un rezultat alcătuit dintr-o singură linie şi o singură coloană Utilitatea acestora este vizibilă în expresii complexe Deşi este prima oară când pomenim de interogări scalare, le-am folosit de multe ori până acum în clauzele WHERE şi HAVING Ceea ce vom parcurge în continuare se referă la includerea unei interogări scalare în clauza SELECT a unei interogări Din păcate, nici Oracle , nici VFP un au implementată această facilitate, aşa încât toate exemplele care urmează sunt specifice DB Care sunt totalurile salariilor tarifare şi ale sporurilor pe luna iulie pentru întreaga firmă? Soluţia clasică este: SELECT SUM(SalTarifar) AS Total Sal Tarifar, SUM ( VALUE(SporVechime, ) + VALUE(SporNoapte, )+ VALUE(SporCD, )+VALUE(AlteSpor, ) ) AS Total Sporuri Iulie - FROM PERSONAL INNER JOIN SPORURI ON PERSONAL Marca=SPORURI Marca WHERE An= AND Luna= întrucât toate persoanele din tabela PERSONAL au lucrat în luna iulie (nu a plecat nici un angajat din organizaţie), se poate formula şi interogarea: SELECT SUM (SalTarifar) Total Sal Tarifar, (SELECT SUM ( VALUE(SporVechime, ) + VALUE(SporNoapte, )+ VALUE(SporCD, )+ VALUE(AlteSpor, )) FROM SPORURI WHERE An= AND Luna= ) AS Total Sporuri Iulie FROM PERSONAL A doua coloană a rezultatului este obţinută printr-o interogare scalară care operează oarecum independent de fraza SELECT principală, furnizându-i însă o valoare Care sunt totalurile vânzărilor şi încasărilor? Formulăm o variantă curioasă: SELECT (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr) AS Facturat, (SELECT SUM (Transa) FROM INCASFACT) AS încasat FROM SYSIBM SYSDUMMY Fraza SELECT conţine două subconsultări scalare: una care extrage totalul vânzărilor, cealaltă, totalul încasărilor Deoarece în clauza FROM era nevoie de o tabelă cu o singură linie, s-a folosit pseudotabela SYS IBM SYSDUMMY (echivalenta [pseudo]tabelei DUAL din Oracle) care are un rând şi un atribut Care este ziua în care s-au emis cele mai multe facturi? SELECT DataFact, COUNT(*) AS Nr Facturi, (SELECT MAX(NrF) FROM (SELECT COUNT(*) AS NrF FROM FACTURI GROUP BY DataFact) Tl ) AS NrMax FROM FACTURI GROUP BY DataFact HAVING COUNT(*) >= (SELECT MAX(NrF) FROM (SELECT COUNT(*) AS NrF FROM FACTURI GROUP BY DataFact) T ) Valorile coloanelor Nr Facturi şi NrMax ale rezultatului din figura sunt furnizate de două subconsultări scalare, una care calculează numărul zilnic al facturilor, iar a doua, număr :, maxim de facturi emise într-o zi  Figura Zilele în care s-au întocmit cele mai multe facturi Care sunt localităţile în care se află sediul fiecărui client? Revenim la un exemplu banal, rezolvat atât de simplu prin joncţiune sau subconsultare, pentru i demonstra cât de mult ne putem complica viaţa în SQL (deşi au fost exemple mai convingătoare Ei bine, această problemă supărător de simplă poate fi rezolvată şi prin subconsultări scalare: SELECT DenCl, (SELECT Loc FROM LOCALITATI WHERE CodPost=CLIENTI CodPost) FROM CLIENŢI ORDER BY Loc Figura este edificatoare în ceea pc priveşte corectitudinea rezultatului interogării Unicul merit al exemplului este, probabil, acela de a demonstra că o subconsultare scalară poate fi corelată cu tabela din clauza FROM a frazei principale DENCL LOC  Clienţi SRL Iasi  Client SA Iasi  Client Paşcani  Client SA Roman  Client SRL Timişoara  Client SRL Timişoara  Client SRL Vaslui   Figura Subconsultare scalară corelată cu tabela din fraza principală Continuăm cu alte exemple în care subconsultările scalare îşi arată pe deplin eficienţa Abia o dată cu apariţia funcţiilor OLAP în SQL- şi versiunile recente ale Oracle ( i ), DB ( şi ) pot fi formulate soluţii bazate pe funcţii şi clauze preferabile subconsultărilor scalare Pentru cât la sută dintre clienţi s-au întocmit, zilnic, facturi? ' SELECT DataFact, COUNT(DISTINCT CodCl) AS Nr Clienţi, (SELECT COUNT(*) FROM CLIENŢI) AS Nr Total Clienţi (COUNT(DISTINCT CodCl) * ) / ~ (SELECT COUNT(*) FROM CLIENŢI) AS Procent FROM FACTURI GROUP BY DataFact DATAFACT NR CLIENTI NR TOTAL CLIENTI PROCENT   - -      - -      - -      - -      - -     Figura Procentajul zilnic al clienţilor pentru care există facturi Pentru a obţine procentul care interesează, se împarte rezultatul calculat de funcţia COUNT pentru fiecare grup (zi calendaristică) la valoarea extrasă de interogarea scalară Care este contribuţia (procentuală) a fiecărui produs la totalul vânzărilor? Informaţia este una esenţială pentru orice firmă Ne vom servi de o subconsultare scalară pentru a determina, pe fiecare linie (corespunzătoare unui produs), totalul vânzărilor şi a face astfel raportul care ne interesează SELECT DenPr AS Produs, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari Produs, (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr ) AS Total Vinzari, (SUM(Cantitate * PretUnit * ( +ProcTVA)) * ) / (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr ) AS Procent FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr GROUP BY DenPr PRODUS VINZARLPRODUS T TAL VINZAR PROCENT  Produs     Produs     Produs     Produs     Produs     Figura Contribuţia fiecărui produs la cifra de afaceri Care este evoluţia zilnică a vânzărilor, raportat la ziua calendaristică anterioară? SELECT DataFact AS Zi, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari Zi Curenta, (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM FACTURI F INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact INNER JOIN PRODUSE P ON LF CodPr=P CodPr WHERE DataFact = F DataFact - DAY ) AS Vinzari Zi Precedenta, SUM(Cantitate * PretUnit * ( +ProcTVA)) - VALUE((SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM FACTURI F INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact INNER JOIN PRODUSE P ON LF CodPr=P CodPr WHERE DataFact = F DataFact - DAY ), ) AS Diferenţa FROM FACTURI F INNER JOIN LINIIFACT LF ON F Nrfact=LF NrFact INNER JOIN PRODUSE P ON LF CodPr=P CodPr GROUP BY DataFact Soluţia este una mai laborioasă, dar şi mai de efect (figura ) Prima interogare scalară furnizează totalul vânzărilor pentru ziua precedentă, ziua curentă fiind cea a grupului de referinţă A doua instanţă a interogării scalare permite calcularea diferenţei dintre vânzările zilei curente şi a celei precedente Funcţia VALUE converteşte valoarea NULL, datorată inexistenţei vânzărilor în data calendaristică precedentă (aşa cum este cazul zilelor de şi august ), în zero Zi ViNZAR ZI CURENTA VINZARI ZI PRECEDENTA DIFERENŢA   - -    '   - -   -   - -   -   - -   -   - -     Figura Diferenţa vânzărilor între ziua curentă şi cea precedentă Care este evoluţia zilnică a vânzărilor, raportat la ziua de vânzări anterioară? In problema de mai sus, diferenţa era calculată între ziua curentă şi ziua precedentă Astfel încât toate zilele de luni erau raportate la zero, deoarece, pentru cea mai mare parte a firmelor, duminica nu se lucrează Acum dorim ca diferenţa să fie calculată între vânzările din ziua curentă şi cele din precedenta zi de vânzări, adică între luni şi vineri ş a m d , după cum se observă în figura ZI VINZARLZLCURENTA VIMZ^RI ZI PRECEDENTA DIFERENŢA   - -      - -   -   - -   -   - -   -   - -     Figura Diferenţele dintre două zile consecutive de vânzări SELECT DataFact AS Zi,SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari Zi Curenta, (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM FACTURI F INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact INNER JOIN PRODUSE P ON LF CodPr=P CodPr WHERE DataFact IN (SELECT MAX(DataFact) FROM FACTURI F INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact INNER JOIN PRODUSE P ON LF CodPr=P CodPr WHERE DataFact ) ) AS Vinzari Zi Precedenta, SUM(Cantitate * PretUnit * ( +ProcTVA)) - VALUE( (SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM FACTURI F INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact INNER JOIN PRODUSE P ON LF CodPr=P CodPr WHERE DataFact IN (SELECT MAX(DataFact) FROM FACTURI F - INNER JOIN LINIIFACT LF ON F NrFact=LF NrFact INNER JOIN PRODUSE P ON LF CodPr=P CodPr WHERE DataFact ) ), ) AS Diferenţa FROM FACTURI F INNER JOIN LINIIFACT LF ON F Nrfact=LF NrFact INNER JOIN PRODUSE P ON LF CodPr=P CodPr GROUP BY DataFact Artificiul necesar extragerii precedentei zi de vânzări se găseşte în subconsultările din cele două interogări scalare Prin joncţiunea instanţelor F şi LF ale tabelelor FACTURI şi LINIIFACT şi condiţia DataFact (ca nu cumva să fie vreo zi în care apare o factură în care liniile să prezinte Cantitate = , deşi situaţia aceasta este greu de imaginat) Dintre zilele de vânzare ce precedă ziua curentă, cea mai apropiată (calendaristic) se extrage prin funcţia MAX Nu ştiu ce ziceţi dumneavoastră, dar mie-mi place, Interogări ierarhice Un titlu mai adecvat al acestui paragraf ar fi fost Ierarhii în SQL sau, şi mai general, Structuri arborescente în SQL Cred că, dintre cei care au scris despre SQL, lider al subiectului este de departe Joe Celko, ce publică periodic un material pe această temă, fie în cărţile sale, fie în reviste precum DBMS Magazine, actualmente Intelligent Enterprise Preambulul discuţiei este plasat în paragraful , unde au fost prezentate două tabele, PERSONAL şi SPORURI Prima dintre acestea reflectă structura ierarhică a firmei, deoarece, pentru fiecare angajat, este indicată şi marca şefului său direct (figura ) Cele câteva chestiuni care sunt descrise în continuare privesc modul în care pot fi făcute comparaţii, analize între angajaţi aflaţi pe anumite niveluri ierarhice, între angajaţi şi şefii lor direcţi (sau indirecţi) - în tabela PERSONAL angajatul cu marca este chiar directorul general, pentru acesta valoarea atributului MarcaŞef fiind NULL  Soluţia clasică - autojoncţiunea Pentru aflarea majorităţii informaţiilor privitoare la ierarhia firmei, soluţia obişnuită în SQL constă în joncţionarea a două instanţe ale tabelei PERSONAL (PI şi P ) după condiţia PI MarcaSef = P Marca Prin interogarea DB (valabilă şi în VFP): SELECT * FROM PERSONAL PI INNER JOIN PERS NAL P ON PI MarcaSef=P Marca se obţine un rezultat de forma celui din figura MARCA INUMEPREN DATANAST) COMPART MARCASEF SALTARIFARI MARCA j NUMEPREN DATANAST COMPARŢ MAR CÂSEF j SALTARIFAR   IANGAJAT  - - | FINANCIAR    ANGAJAŢI  - - DIRECŢIUNE i   iANGAJAT  - - jMARKETiNG   :  [ANGAJAT  - - DIRECŢIUNE   lOiANGAJAT  - - IRESURSEUMANE   =  : ANGAJAT  - - DIRECŢIUNE    ANGAJAT ! FINANCIAR   I  I ANGAJAT  - - financiar    ; ANGAJAT  - - IFINANCIAR   ‘  !ANGAJAT  - - FINANCIAR    : ANGAJAT  - - : MARKETING   S G :  ! ANGAJAT  - - MARKETING    ! ANGAJAT  - - 'MARKETING   :  iANGAJAT  - - MARKETING    i ANGAJAT  - - IFINANCIAR   :  !ANGAJAT  - - FINANCIAR    ! ANGAJAT i FINANCIAR   :  ! ANGAJAT  - - FINANCIAR   Figura Autojoncţiunea tabelei PERSONAL Primele şase coloane corespund primei instanţe, PI, în timp ce restul - celei de-a doua instanţe, P PI este legată de calitatea de subordonat, iar P de cea de şef De aceea, este mai nimerită denumirea lui PI ca SUBORDONAŢI, iar a lui P , ŞEFI Să luăm în discuţie câteva probleme Cum se numeşte şeful Angajatului ? Soluţie SQL- /DB /VFP: SELECT SEFI NumePren FROM PERSONAL SUBORDONAŢI INNER JOIN PERSONAL SEFI ON SUBORDONAŢI MarcaSef = SEFI Marca WHERE SUBORDONAŢI NumePren = 'ANGAJAT ' Care sunt subordonaţii direcţi ai Angajatului ? Soluţie SQL- /DB /VFP: SELECT SUBORDONAŢI NumePren FROM PERSONAL SUBORDONAŢI INNER JOIN PERSONAL SEFI ON SUBORDONAŢI MarcaSef = SEFI Marca WHERE SEFI NumePren = 'ANGAJAT ' Fireşte, cele două probleme pot fi rezolvate şi prin subconsultări, astfel : SELECT NumePren FROM PERSONAL WHERE Marca IN (SELECT MarcaSef FROM PERSONAL WHERE NumePren = 'ANGAJAT ') respectiv: SELECT NumePren FROM PERSONAL WHERE MarcaSef IN (SELECT Marca FROM PERSONAL WHERE NumePren = 'ANGAJAT ') Ultimele două soluţii sunt valabile în aproape orice SGBD Câţi subordonaţi are fiecare angajat al firmei? Soluţia: SELECT SEFI NumePren, COUNT(*) AS Nr Subordonati FROM PERSONAL SUBORDONAŢI INNER JOIN PERSONAL SEFI ON SUBORDONAŢI MarcaSef = SEFI Marca GROUP BY SEFI NumePren extrage numai pe cei care au măcar un subordonat Dacă dorim ca rezultatul să conţină toţi angajaţii în ordine alfabetică, trebuie folosită joncţiunea externă la dreapta şi modificat argumentul funcţiei COUNT: SELECT SEFI NumePren, COUNT(SUBORDONAŢI MarcaSef) AS Nr Subordonati FROM PERSONAL SUBORDONAŢI RIGHT OUTER JOIN PERSONAL SEFI ON SUBORDONAŢI MarcaSef = SEFI Marca GROUP BY SEFI NumePren Figura conţine urmările acestei interogări NUMEPREN NR SUBORDONAŢI  ANGAJAT   ANGAJAT   ANGAJAT   ANGAJAT   ANGAJAT   ANGAJAT   ANGAJAT   ANGAJAT   ANGAJAT   ANGAJAT    Figura Numărul subordonaţilor pentru fiecare salariat Care sunt subordonaţii subordonaţilor directorului general? Din punctul de vedere al arborelui ce oglindeşte ierarhia firmei (figura ), ne interesează „nepoţii rădăcinii” Interogarea trebuie să parcurgă trei niveluri ierarhice şi, în final, să extragă salariaţii cu mărcile , , şi  Figura Ierarhia firmei Varianta (generală): SELECT SUBORDONAŢI Marca, SUBORDONAŢI NumePren, SUBORDONAŢI Compart FROM PERSONAL SUBORDONAŢI INNER JOIN PERSONAL SEFI ON SUBORDONAŢI MarcaSef = SEFI Marca INNER JOIN PERSONAL SEFI ON SEFI MarcaSef = SEFI Marca WHERE SEFI MarcaSef IS NULL Varianta non-VFP (două niveluri de subconsultare): SELECT Marca, NumePren, Compart FROM PERSONAL WHERE MarcaSef IN (SELECT Marca FROM PERSONAL WHERE MarcaSef IN (SELECT Marca FROM PERSONAL WHERE MarcaSef IS NULL) ) Care este nivelul ierarhic al fiecărui salariat? De la început, ştim că ierarhia reflectată în tabela PERSONAL se derulează pe patru niveluri, aşa încât o interogare pentru rezolvarea problemei poate fi: SELECT 'Nivel ' AS Nivel, NumePren, Compart FROM PERSONAL WHERE MarcaSef IS NULL UNION SELECT 'Nivel ' AS Nivel, NIVEL NumePren, NIVEL Compart FROM PERSONAL NIVEL INNER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef AND Nivell MarcaSef IS NULL UNION SELECT 'Nivel ' AS Nivel, NIVEL NumePren, NIVEL Compart FROM PERSONAL NIVEL INNER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef AND Nivell MarcaSef IS NULL INNER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef UNION SELECT 'Nivel ' AS Nivel, NIVEL NumePren, NIVEL Compart FROM PERSONAL NIVEL INNER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef AND Nivell MarcaSef IS NULL INNER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef INNER JOIN PERSONAL NIVEL • ON NIVEL Marca = NIVEL MarcaSef ORDER BY NumePren Iată şi rezultatul NUMEPREN COMPART NIVEL  ANGAJAT DIRECŢIUNE Nivel  ANGAJAT RESURSE UMANE Nivel  ANGAJAT FINANCIAR Nivel  ANGAJAT MARKETING Nivel  ^ANGAJAT FINANCIAR Nivel  ANGAJAT FINANCIAR Nivel  ANGAJAT FINANCIAR Nivel  ANGAJAT FINANCIAR Nivel  ANGAJAT Wrketing Nivel  ANGAJAT MARKETING Nivel   Figura Nivelul ierarhic al fiecărui angajat Pentru Visual FoxPro, diferenţa principală ţine de regimul clauzei ORDER BY Aceasta trebuie să fie ataşată primei fraze SELECT din reuniune în plus, paradoxal, coloana de ordonare poate fi indicată numai prin număr (în această situaţie) SELECT-ul care obţine rezultatul din figura este: SELECT 'Nivel ' AS Nivel, NumePren, Compart ; FROM PERSONAL ; WHERE MarcaSef IS NULL ; ORDER BY ; UNION ; SELECT 'Nivel ' AS Nivel, NIVEL NumePren, NIVEL Compart ; FROM PERSONAL NIVEL ; INNER JOIN PERSONAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef AND ; Nivell MarcaSef IS NULL ; UNION ; SELECT 'Nivel ' AS Nivel, NIVEL NumePren, NIVEL Compart ; FROM PERSONAL NIVEL ; INNER JOIN PERS NAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef AND ; Nivell MarcaSef IS NULL ; INNER JOIN PERSONAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef ; UNION ; SELECT 'Nivel ' AS Nivel, NIVEL NumePren, NIVEL Compart ; FROM PERSONAL NIVEL ; INNER JOIN PERS NAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef AND ; Nivell MarcaSef IS NULL ; INNER JOIN PERSONAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef ; INNER JOIN PERS NAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef Interogarea funcţionează rezonabil Există însă cel puţin două umbre: trebuie să ştim, aprioric, numărul nivelurilor ierarhice, iar în al doilea rând, la un număr mult mai mare de niveluri, întinderea consultării creşte sensibil O variantă mai elegantă, ca volum de scris, nu şi ca resurse consumate, este: SELECT NIVEL *, CASE WHEN NIVEL MarcaSef IS NULL THEN WHEN NIVEL MarcaSef IS NULL THEN WHEN NIVEL MarcaSef IS NULL THEN WHEN NIVEL MarcaSef IS NULL THEN END AS Nivel FROM PERSONAL NIVEL RIGHT OUTER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef AND Nivell MarcaSef IS NULL RIGHT OUTER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef RIGHT OUTER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef Se joncţionează extern patru instanţe ale tabelei PERSONAL , câte una pentru fiecare nivel ierarhic, astfel încât au şi fost denumite NI VEL NIVEL MARCA |NUMEPREN DATANAST COMPART MARCASEF SALTARIFAR NIVEL   ANGAJAT  - - DIRECŢIUNE      ANGAJAT  - - RESURSE UMANE      ANGAJAT  - - FINANCIAR      ANGAJAT  - - MARKETING      ANGAJAT  FINANCIAR      ANGAJAT  - - FINANCIAR      ANGAJAT  - - FINANCIAR      ANGAJAT  FINANCIAR      ANGAJAT  - - MARKETING      ANGAJAT S i - - MARKETING      Figura Soluţie DB pentru aflarea nivelului ierarhic al fiecărui angajat Fraza SELECT compune ierarhia pornind de la NIVEL , care reprezintă o instanţă a PERSONAL cu o singură linie, cea a directorului general, instanţă joncţionată extern la dreapta cu NIVEL , care va furniza subordonaţii direcţi ai înregistrării-rădăcină ş a m d Transcrisă în dialectul VFP, interogarea se prezintă astfel: SELECT NIVEL *, ; IIF(ISNULL(NIVEL MarcaSef), , ; IIF(ISNULL(NIVEL MarcaSef), , ; IIF(ISNULL(NIVEL MarcaSef), , ) ) ) AS Nivel ; FROM PERSONAL NIVEL ; RIGHT OUTER JOIN PERSONAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef AND ; Nivell MarcaSef IS NULL ; RIGHT OUTER JOIN PERSONAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef ; RIGHT OUTER JOIN PERSONAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef ; Să se afişeze structura ierarhică a firmei Practic, dorim o formă de vizualizare a angajaţilor care să ţină cont de modul lor de subordonare - ca în figura NUME COMPART SEF SEF I SEF SEF  ANGAJAŢI DIRECŢIUNE       ANGAJAT FINANCIAR       ANGAJAT FINANCIAR       ANGAJAT FINANCIAR       ANGAJAT FINANCIAR       ANGAJAT FINANCIAR       ANGAJAT MARKETING       ANGAJAT MARKETING       ANGAJAT MARKETING       ANGAJAT RESURSE UMANE V     Figura Vizualizarea ierarhiei Dintre variantele DB operaţionale, începem cu una destul de stufoasă, bazată pe expresia tabelă NIVELE WITH NIVELE AS (SELECT NIVEL *, CASE WHEN NIVEL MarcaSef IS NULL THEN WHEN NIVEL MarcaSef IS NULL THEN WHEN NIVEL MarcaSef IS NULL THEN WHEN NIVEL MarcaSef IS NULL THEN END AS Nivel FROM PERSONAL NIVEL RIGHT OUTER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef AND Nivell MarcaSef IS NULL RIGHT OUTER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef RIGHT OUTER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef ) SELECT NIVELE NumePren AS Nume, NIVELE Compart, NIVELE Marca AS Sefl, NIVELE Marca AS Sef , NIVELE Marca AS Sef , NIVELE Marca AS Sef FROM NIVELE WHERE Nivel = ■ UNION SELECT ' '||N NumePren AS Nume, N Compart, NI Marca AS Sefl, N Marca AS Sef , N Marca AS Sef , N Marca AS Sef FROM NIVELE N INNER JOIN NIVELE NI ON N Nivel= AND N MarcaSef=Nl Marca AND Nl Nivel=l UNION SELECT ' '||N NumePren AS Nume, N Compart, NI Marca AS Sefl, N Marca AS Sef , N Marca AS Sef , N Marca AS Sef FROM NIVELE N INNER JOIN NIVELE N ON N Nivel= AND N MarcaSef=N Marca AND N Nivel= INNER JOIN NIVELE NI ON N Nivel= AND N MarcaSef=Nl Marca AND Nl Nivel=l UNION SELECT ' ' | |N NumePren AS Nume, N Compart, NI Marca AS Sefl, N Marca AS Sef , N Marca AS Sef , N Marca AS Sef FROM NIVELE N INNER JOIN NIVELE N ON N Nivel= AND N MarcaSef=N Marca AND N Nivel= INNER JOIN NIVELE N ON N Nivel= AND N MarcaSef=N Marca AND N Nivel= INNER JOIN NIVELE NI ON N Nivel= AND N MarcaSef=N Marca AND Nl Nivel=l ORDER BY Sefl Sef , Sef Sef Lucrurile pot fi simplificate sensibil utilizând o structură de tip CASE, prin care determinăm nivelul de subordonare, nivel care va determina de câte ori se repetă (funcţia DB REPEAT) grupul de şase liniuţe, astfel încât listarea primei coloane este asemănătoare celei din figura SELECT RTRIM ( CHAR ( REPEAT * ( ( CASE WHEN NIVEL MarcaSef IS NULL THEN WHEN NIVEL MarcaSef IS NULL THEN WHEN NIVEL MarcaSef IS NULL THEN WHEN NIVEL MarcaSef IS NULL THEN END ) - ) ) ) ) M NIVEL NumePren AS Nume, NIVEL Compart FROM PERSONAL NIVEL RIGHT OUTER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef AND Nivel MarcaSef IS NULL RIGHT OUTER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef RIGHT OUTER JOIN PERSONAL NIVEL ON NIVEL Marca = NIVEL MarcaSef In VFP, acelaşi rezultat se obţine printr-un lanţ de IF-uri imediate (IIF-uri): SELECT REPLICATE, (IIF(ISNULL(NIVEL MarcaSef), , ; IIF(ISNULL(NIVEL MarcaSef), , ; IIF(ISNULL(NIVEL MarcaSef), , ) ) ) - ) ; )+NIVEL NumePren AS Nume, NIVEL Compart ; FROM PERSONAL NIVEL ; RIGHT OUTER JOIN PERSONAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef AND ; Nivell MarcaSef IS NULL ; RIGHT OUTER JOIN PERSONAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef ; RIGHT OUTER JOIN PERSONAL NIVEL ; ON NIVEL Marca = NIVEL MarcaSef Interogări arborescente în Oracle Pentru problemele formulate în acest paragraf, până acum au fost formulate numai soluţii DB şi VFP, lăsând să se înţeleagă că formularea variantelor echivalente în Oracle ar fi o temă pentru acasă/la birou De fapt ne-am rezervat pentru paginile care urmează Dialectul SQL al Oracle are câteva opţiuni speciale pentru parcurgerea structurilor ierarhice, cele mai importante fiind START WITH şi CONNECT BY Care este nivelul ierarhic al fiecărui salariat? Soluţia următoare conduce la rezultatul din figura SELECT PERSONAL *, LEVEL FROM PERSONAL START WITH MarcaSef IS NULL CONNECT BY PRIOR Marca=MarcaSef Construirea structurii ierarhice începe cu înregistrarea (înregistrările) care îndeplineşte (îndeplinesc) condiţia din clauza START WITH Această înregistrare-părinte va fi legată de înregistrarea sau înregistrările-copil prin condiţia Marca = MarcaSef Clauza PRIOR plasată în stânga condiţiei semnifică: valoarea atributului Marca din părinte trebuie să fie egală cu valoarea MarcaSef din înregistrările-copil MARCA NUMEPREN DATANAST COMPART MARCASEF SALTARIFAR LEVEL   ANGAJAT  -JUL- DIRECŢIUNE      ANGAJAT  -OCT- FINANCIAR      ANGAJAT  FINANCIAR      ANGAJAT  -APR- FINANCIAR      ANGAJAT  -NOV- FINANCIAR      ANGAJAT  FINANCIAR      ANGAJAT  -AUG- MARKETING      ANGAJAT  -DEC- MARKETING      ANGAJAT  -FEB- MARKETING      ANGAJAT  -JAN- RESURSE UMANE     Figura Interogare ierarhică Prin CONNECT BY sunt selectate toate generaţiile succesive de linii-copil (copii, nepoţi, strănepoţi etc ) După construirea ierarhiei, se elimină tuplurile ce nu îndeplinesc condiţia formulată în clauza WHERE Este important de notat că selecţia se aplică linie cu linie, iar eliminarea unei linii-părinte nu atrage automat eliminarea copiilor, nepoţilor ş a m d Dacă există clauza ORDER BY, aceasta va determina dispunerea înregistrărilor în rezultat In lipsa clauzei de ordonare, înregistrările sunt dispuse în funcţie de ordinea parcurgerii arborelui, aşa cum se observă din figura Un avantaj major al interogărilor ierarhice ţine de folosirea pseudocoloanei LEVEL, ce semnifică tocmai nivelul ierarhiei, relativ la înregistrarea/înregistrările-„rădăcină” care îndeplineşte/îndeplinesc condiţia din START WITH Ca principale restricţii trebuie amintit că SELECT-ul care execută o interogare ierarhică nu poate efectua o joncţiune şi nici extrage date dintr-o tabelă virtuală creată printr-o joncţiune Cum se numeşte şeful Angajatului ? Dacă folosim interogarea: SELECT PERSONAL *, LEVEL FROM PERSONAL START WITH NumePren = 'ANGAJAT ' CONNECT BY PRIOR MarcaSef = Marca se obţine: MARCA NUMEPREN DATANAST COMPART MARCASEF SALTARIFAR LEVEL   ANGAJAT  FINANCIAR      ANGAJAT  -APR- FINANCIAR      ANGAJAT  -OCT- FINANCIAR      ANGAJAT  -JUL- DIRECŢIUNE      Răspunsul exact la întrebare (figura ) presupune următoarea soluţie: SELECT PERSONAL *, LEVEL FROM PERSONAL WHERE LEVEL - = ( SELECT LEVEL FROM PERSONAL WHERE NumePren = 'ANGAJAT ' START WITH NumePren = 'ANGAJAT ' CONNECT BY PRIOR MarcaSef = Marca ) START WITH NumePren = 'ANGAJAT ' CONNECT BY PRIOR MarcaSef = Marca MARCA [NUMEPREN |DATANAST [COMPART |MARCASEF |SALTARIFAR [LEVEL ANGAJAT -APR- FINANCIAR Figura Şeful direct al Angajatului Care sunt subordonaţii direcţi ai Angajatului ? Subordonaţii de ordin (direcţi), , , adică cei din figura , pot fi extraşi prin: SELECT PERSONAL *, LEVEL FROM PERSONAL START WITH NumePren = 'ANGAJAT ' CONNECT BY MarcaSef = PRIOR Marca MARCA [NUMEPREN |DATANAST[COMPART [MARCASEF |SALTARIFAR | LEVEL   ANGAJAT  -OCT- FINANCIAR  h   ANGAJAT FINANCIAR     ANGAJAT  -APR- FINANCIAR     ANGAJAT  -NOV- FINANCIAR     ANGAJAT FINANCIAR    Figura Toţi subordonaţii Angajatului Ca să obţinem răspunsul punctual la întrebare, apelăm la o subconsultare: SELECT PERSONAL *, LEVEL FROM PERSONAL WHERE LEVEL - = (SELECT LEVEL FROM PERSONAL WHERE NumePren = 'ANGAJAT ' START WITH NumePren = 'ANGAJAT ' CONNECT BY PRIOR MarcaSef = Marca) START WITH NumePren = 'ANGAJAT ' CONNECT BY MarcaSef = PRIOR Marca Care sunt subordonaţii subordonaţilor directorului general? Acestea sunt înregistrările-„nepot” ale înregistrării-rădăcină (MarcaSef IS NULL) O soluţie bazată tot pe pseudocoloana LEVEL şi o subconsultare este: islll fiii-!,:!!,: pHii-: : : SELECT PERS NAL *, LEVEL FROM PERSONAL WHERE LEVEL - = (SELECT LEVEL FROM PERSONAL WHERE MarcaSef IS NULL START WITH MarcaSef IS NULL CONNECT BY PRIOR MarcaSef = Marca ) START WITH MarcaSef IS NULL CONNECT BY MarcaSef = PRIOR Marca însă dacă ţinem seama că nivelul ierarhic al directorului general este , al subordonaţilor săi direcţi este , iar al subordonaţilor subordonaţilor este , soluţia se simplifică apreciabil: SELECT PERSONAL *, LEVEL FROM PERSONAL WHERE LEVEL = START WITH MarcaSef IS NULL CONNECT BY MarcaSef = PRIOR Marca Să se afişeze structura ierarhică a firmei Nu putem să reprezentăm arborele ierarhic cu „verdele în jos”, ci cu rădăcina la stânga, la fel ca în soluţia DB de acum câteva figuri Indentarea subordonaţilor se obţine cu ajutorul funcţiei LPAD şi psedoatributului LEVEL după cum urmează: SELECT LPAD(' ', *(LEVEL - ), || numepren AS Nume, Compart FROM PERS NAL START WITH MarcaSef IS NULL CONNECT BY PRIOR Marca = MarcaSef în lipsa unei condiţii formulate în clauza START WITH, se construieşte câte o ierarhie pentru fiecare angajat (fiecare angajat va fi, pe rând, rădăcină a unei ierarhii) Astfel, interogarea următoare va genera rezultatul din figura NUME COMPART  ANGAJAT DIRECŢIUNE  — ANGAJAT FINANCIAR  - ANGAJAT FINANCIAR   ANGAJAT FINANCIAR  - ANGAJAT FINANCIAR  — ANGAJAT FINANCIAR  —- ANGAJAT MARKETING   ANGAJAT MARKETING  — ANGAJAT MARKETING  — ANGAJAT RESURSE UMANE   NUME COMPART  ANGAJAT DIRECŢIUNE   ANGAJAT FINANCIAR   — ANGAJAT FINANCIAR   — ANGAJAT FINANCIAR   - ANGAJAT FINANCIAR   ANGAJAT FINANCIAR   ANGAJAT MARKETING   ANGAJAT MARKETING   ANGAJAT MARKETING   ANGAJAT RESURSE UMANE  ANGAJAT FINANCIAR  — ANGAJAT FINANCIAR   ANGAJAT FINANCIAR  - - ANGAJAT FINANCIAR   - ANGAJAT FINANCIAR  ANGAJAT MARKETING  — ANGAJAT MARKETING   ANGAJAT MARKETING  ANGAJAT FINANCIAR  ANGAJAT FINANCIAR   ANGAJAT FINANCIAR  — ANGAJAT FINANCIAR  ANGAJAT FINANCIAR  ANGAJAT FINANCIAR  ANGAJAT MARKETING  ANGAJAT MARKETING  ANGAJAT RESURSE UMANE   Figura Ierarhii pentru fiecare angajat SELECT LPAD(' *(LEVEL - ), || numepren AS Nume, Compart FROM PERSONAL CONNECT BY PRIOR Marca = MarcaSef Primele zece înregistrări reprezintă structura ierarhică pentru care rădăcina este directorul general; liniile - ale rezultatului constituie ierarhia a cărei bază este Angajat ş a m d Actualizarea tabelelor prin subconsultări Pentru o mai bună priză la public, în cele ce urmează apelăm la ceea ce se numeşte de-normalizarea bazei de date în practică, redundanţa datelor este uneori condamnată cu jumătate de gură sau chiar apreciată de mulţi specialişti Aceasta deoarece un atribut redundant, adăugat unei tabele, poate duce la evitarea joncţiunilor frecvente, mari consumatoare de resurse Aplecându-ne asupra bazei noastre de date, dacă tot ne apucăm de treabă, în tabela FACTURI adăugăm nu mai puţin de trei atribute: ValTotală reprezintă valoarea totală (inclusiv TVA) a facturii; Reduceri: într-o ţară civilizată, ca a noastră, dacă un client plăteşte o factură înainte de termenul obişnuit (să zicem zece zile), îi putem acorda o reducere de % pentru că ne-am procopsit rapid cu lichidităţi Penalităţi: este opusul atributului anterior Prin contract sau prin lege, dacă un client este mai reţinut în a plăti facturile la timp, i se pot aplica penalităţi, fară a avea însă certitudinea că le-am putea încasa vreodată Practic, prin aceste noi atribute, urmărirea încasării facturilor se schimbă sensibil Valoarea de încasat dintr-o factură este valoarea totală plus penalităţi minus reduceri Asta e vestea bună Vestea proastă ţine de faptul că atributul ValTotală n-ar trebui să se modifice decât la actualizarea tabelei LINIIFACT, nu? Altminteri, dacă utilizatorul ar modifica, prin UPDATE sau alt mijloc, acest atribut, ar apărea un decalaj supărător între liniile din facturi şi valorile acestora Actualizarea automată a unor atribute calculate este unul din scopurile declarate ale declanşatoarelor (trigger-elor), după cum vom vedea în capitolul Deocamdată adăugăm cele trei atribute tabelei FACTURI: ALTER TABLE FACTURI ADD ValTotala DECIMAL( ) ; ALTER TABLE FACTURI ADD Reduceri DECIMAL( ) ; ALTER TABLE FACTURI ADD Penalizari DECIMAL( ) ; Acum, dacă tot le-am creat, să le „umplem” Astfel, pentru calculul valorii totale a unei facturi avem nevoie de o interogare corelată după cum urmează: UPDATE FACTURI SET ValTotala = ( SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM LINIIFACT LF INNER JOIN PRODUSE P ON LF CodPr=P CodPr WHERE NrFact = FACTURI NrFact ) Subconsultarea ia în calcul cantitatea, preţul unitar şi procentul TVA pentru fiecare produs vândut Prin corelare se vor lua în considerare numai liniile din LINIIFACT (şi PRODUSE) corespunzătoare facturii curente (linia curentă din FACTURI) In Oracle, singura deosebire ţine de exprimarea joncţiunii interne: UPDATE FACTURI SET ValTotala = ( SELECT SUM(Cantitate * PretUnit * ( +ProcTVA)) FROM LINIIFACT LF, PRODUSE P WHERE LF CodPr=P CodPr AND NrFact = FACTURI NrFact ) Cu regretele de rigoare, trebuie să constatăm că şi această interogare este prea savantă pentru dialectul SQL din VFP Astfel, toate comenzile de actualizare următoare vor fi tratate cu ostilitate de acest SGBD Cât priveşte atributul Reduceri, instituim următoarea regulă: se acordă o reducere de % pentru toate tranşele unei facturi încasate în termen de zile de la data vânzării UPDATE FACTURI SET Reduceri = ( SELECT SUM ( CASE WHEN Datainc  Client SRL Produs  !  Client SRL   !  Client Produs  i  Client Produs  !  Client   ;  Client SRL Produs  !  Client SRL Produs  !  Client SRL   j  Client SA Produs   Client SA Produs   Client SA Produs   Client SA   !  Client SRL Produs  !  Client SRL   )   Produs  !   Produs  !   Produs  !   Produs  !   Produs  !     i   Figura Analiză pe două dimensiuni Pentru astfel de situaţii există un operator cuceritor prin simplitate: CUBE Cu ajutorul acestuia, se poate redacta următoarea variantă DB , valabilă şi Oracle i (schimbând sintaxa j oncţiunii): SELECT DenCl AS Client, DenPr AS Produs, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCl GROUP BY CUBE (DenCl, DenPr ) ORDER BY DenCl, DenPr Un plus de atractivitate a rezultatului presupune folosirea clauzei GROUPING astfel: SELECT CASE GROUPING (DenCl) WHEN THEN CASE GROUPING (DenPr) WHEN THEN CHR( ) || CHR( ) || ' TOTAL ' ELSE CHR( ) || ' Total PRODUS' END ELSE DenCl END AS Client, - CASE GROUPING (DenPr) WHEN THEN CASE GROUPING (DenCl) WHEN THEN CHR( ) | [ CHR( ) | | ' GENERAL ' ELSE CHR( ) || ' Total CLIENT ' END ELSE DenPr END AS Produs, ■ SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCI GROUP BY CUBE (DenCl, DenPr ) ORDER BY DenCl, DenPr Drept răsplată, forma raportului este cea din figura Ultima linie este cea a totalului general Se cuvine de adăugat că atributele care definesc dimensiunile de analiză trebuie să fie de acelaşi tip Varianta Oracle este în acelaşi gen, doar că, în afara joncţiunii, trebuie modificat şi modul de scriere a secvenţei CASE din fraza DB : SELECT CASE WHEN GROUPING (DenCl) = THEN CASE WHEN GROUPING (DenPr) = THEN CHR( ) || CHR( ) || ' TOTAL ' ELSE CHR( ) || ' Total PRODUS' END ELSE DenCl END AS Client, CASE WHEN GROUPING (DenPr) = THEN CASE WHEN GROUPING (DenCl) = THEN CHR( ) || CHR( ) || ' GENERAL ' ELSE CHR( ) || ' Total CLIENT ' END ELSE DenPr END AS Produs, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C, LOCALITATI L, JUDEŢE J WHERE P CodPr=LF Codpr AND LF NrFact=F NrFact AND F CodCl=C CodCl AND C CodPost=L CodPost AND L Jud=J Jud GROUP BY CUBE (DenCl, DenPr ) ORDER BY DenCl, DenPr CLIENT PRODUS VINZARI  Clienţi SRL Produs   Clienţi SRL Produs   Clienţi SRL Produs   Clienţi SRL y Total CLIENT   Client SA Produs   Client SA yTotal CLIENT   Client SRL Produs   Client SRL Produs   Client SRL Produs   Client SRL Produs   Client SRL yTotal CLIENT   Client Produs   Client Produs   Client yTotal CLIENT   Client SRL Produs   Client SRL Produs   Client SRL yTotal CLIENT   Client SA Produs   Cliente SA Produs   Cliente SA Produs   Client SA yTotal CLIENT   Client SRL Produs   Client SRL yTotal CLIENT   yTotal PRODUS Produs   y Total PRODUS Produs   y Total PRODUS Produs   y Total PRODUS Produs   y Total PRODUS Produs   WTOTAL yy GENERAL    Figura , Variantă DB de utilizare a operatorului CUBE Atunci când analiza se întreprinde pe trei axe: clienţi, produse şi zile, interogarea DB se schimbă astfel: SELECT CASE GROUPING (DenCl) WHEN THEN CONCAT (CHR( ), ' subtotal ') ELSE DenCl END AS Client, CASE GROUPING (DenPr) WHEN THEN CONCAT (CHR( ), 'subtotal ') ELSE DenPr END AS Produs, i: ■Kt mjAjjp- ; CASE GROUPING (CAST( DataFact AS CHAR( ) ) ) WHEN THEN CONCAT (CHR( ), ' subtotal ') ELSE CAST( DataFact AS CHAR( ) ) END AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCI GROUP BY CUBE (DenCl, DenPr, CAST( DataFact AS CHAR( ) ) ) ORDER BY DenCl, DenPr, CAST (DataFact AS CHAR( ) ) Prin CAST s-a realizat conversia din dată calendaristică în şir de caractere Rezultatul, fiind mai lung de o pagină, este afişat sub formă de tabel Cu acest prilej, l-am mai cosmetizat un pic Tabelul Analiză pe trei dimensiuni * CLIENT PRODUS ZIUA VINZARI  Cl ent SRL Produs  / /   Cl ent SRL Produs  / /   Cl ent SRL Produs  / /   Cl ent SRL Produs subtotal   Cl ent SRL Produs  / /   Cl ent SRL Produs  / /   Cl ent SRL Produs  / /   C! ent SRL Produs  / /   Cl ent SRL Produs  / /   Cl ent SRL Produs subtotal   Cl ent SRL Produs  / /   Cl ent SRL Produs subtotal   Cl ent SRL subtotal  / /   Cl ent SRL subtotal ,  / /   Cl ent SRL subtotal  / /   Cl ent SRL subtotal  / /   Cl ent SRL subtotal  / /   Cl ent SRL subtotal subtotal   Cl ent SA Produs  / /   Cl ent SA Produs subtotal   Cl ent SA subtotal  / /   Cl ent SA subtotal subtotal   Cl ent SRL Produs  / /   Cl ent SRL Produs subtotal   Cl ent SRL Produs  / /   Cl ent SRL Produs subtotal   Cl ent SRL Produs  / /    subtotal Produs  / /   subtotal Produs  / /   subtotal Produs subtotal   subtotal Produs  / /   subtotal Produs  / /   subtotal Produs subtotal   subtotal subtotal  / /   subtotal subtotal  / /   subtotal subtotal  / /   subtotal subtotal  / /   subtotal subtotal  / /   subtotal subtotal subtotal    Obţinerea aceluiaşi rezultat utilizând operatorul CUBE presupune, în Oracle i , următoarea interogare: SELECT CASE WHEN GROUPING (DenCl) = THEN ' subtotal ' ELSE DenCl END AS Client, CASE WHEN GROUPING (DenPr) = THEN ' subtotal ' ELSE DenPr END AS Produs, CASE WHEN GROUPING (TO CHAR(DataFact,'DD-MM-YYYY')) = THEN ' subtotal ' ELSE TO CHAR(DataFact,'DD-MM-YYYY') END AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C, LOCALITATI L, JUDEŢE J WHERE P CodPr=LF Codpr AND LF NrFact=F NrFact AND F CodCl=C CodCI AND C CodPost=L CodPost AND L Jud=J Jud GROUP BY CUBE (DenCl, DenPr, TO CHAR(DataFact,'DD-MM-YYYY')) In absenţa operatorului CUBE, SQL- cere ceva efort de scriere, deşi logica interogării este relativ simplă: SELECT DenCl AS Client, DenPr AS Produs, CAST( DataFact AS CHAR( ) ) AS Ziua, ' SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCI GROUP BY DenCl, DenPr, CAST( DataFact AS CHAR( ) ) UNION SELECT DenCl AS Client, DenPr AS Produs, CHR( ) ]| ' subtotal ' AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCI GROUP BY DenCl, DenPr UNION SELECT DenCl AS Client, CHR( ) || ' subtotal ' AS Produs, CAST( DataFact AS CHAR( ) ) AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCi=C CodCI GROUP BY DenCl, CAST( DataFact AS CHAR( ) ) UNION SELECT CHR( ) | i ' subtotal ' AS Client, DenPr AS Produs, CAST( DataFact AS CHAR( ) ) AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCI GROUP BY Den-Pr, CAST ( DataFact AS CHAR ( ) ) UNION SELECT DenCi AS Client, CHR( ) i | ' subtotal ' AS Produs, CHR( ) || ' subtotal ' AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCI GROUP BY DenCl UNION SELECT CHR( ) || subtotal ' AS Client, DenPr AS Produs, CHR( ) || ' subtotal ' AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCI GROUP BY DenPr UNION SELECT CHR( ) !| ' subtotal ' AS Client, CHR( ) || ' subtotal ' AS Produs, CAST( DataFact AS CHAR( ) ) AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCl GROUP BY CAST( DataFact AS CHAR( ) ) UNION SELECT CHR( ) || ' subtotal ' AS Client, CHR( ) || ' subtotal ' AS Produs, CHR( ) || ' subtotal ' AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCl ORDER BY Client, Produs, Ziua Operatorul GROUPING SETS Uneori, prea multă detaliere, precum cea din tabelul de mai sus, devine obositoare Prin GROUPING SETS se poate regla granularitatea agregărilor Dacă, spre exemplu, în interogarea anterioară se doreşte urmărirea zilnică a vânzărilor pentru fiecare client (şi toate produsele) şi pentru fiecare produs (şi toţi clienţii), se poate recurge la varianta următoare: SELECT CASE GROUPING (DenCl) WHEN THEN CONCAT (CHR( ), ' -subtotal- ') ELSE DenCl END AS Client, CASE GROUPING (DenPr) WHEN THEN CONCAT (CHR( ), ' -subtotal- ') ELSE DenPr END AS Produs, CASE GROUPING (CAST( DataFact AS CHAR( ) ) ) WHEN THEN CONCAT (CHR( ), ' -subtotal- ') ELSE CAST( DataFact AS CHAR( ) ) END AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCl GROUP BY GROUPING SETS ( (DenCl, DenPr), CAST( DataFact AS CHAR( )) ) ORDER BY DenCl, DenPr, CAST (DataFact AS CHAR( ) ) în clauza GROUP BY a fost introdus operatorul GROUPING SETS, prin care se precizează două grupuri de agregare, unul alcătuit din combinaţia (DenCl, DenPr), celălalt din data facturii, astfel încât se obţine un rezultat cum este cel din figura Dacă se doreşte o situaţie sintetică cu subtotaluri ale celor trei atribute, plus un total general (obţinut prin perechea de paranteze fară argumente), se schimbă clauza GROUP BY astfel: CLIENT PRODUS ZIUA VINZARI  Clienţi SRL Produs y-subtotal-   Clienţi SRL Produs y-subtotal-   Clienţi SRL Produs y-subtotal-   Client SA Produs y-subtotal-   Client SRL Produs y-subtotal-   Client SRL Produs y-subtotal-   Client SRL Produs y-subtotal-   Client SRL Produs y-subtotal-   Client Produs y-subtotal-   Client Produs y-subtotal-   Client SRL Produs y-subtotal-   Client SRL Produs y-subtotal-   Client SA Produs y-subtotal-   Client SA Produs y-subtotal-   Client SA Produs y-subtotal-   Client SRL Produs y-subtotal-   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal-  - -   y-subtotal- v-subtotal-  - -   Figura Clauza GROUPING SETS SELECT CASE GROUPING (DenCl) WHEN THEN CONCAT (CHR( ), ' -subtotal- ') ELSE DenCl END AS Client, CASE GROUPING (DenPr) WHEN THEN CONCAT (CHR( ), ' -subtotal- ') ELSE DenPr END AS Produs, CASE GROUPING (CAST( DataFact AS CHAR( ) ) ) WHEN THEN CONCAT (CHR( ), ' -subtotal- ') ELSE CAST( DataFact AS CHAR( ) ) END AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCl GROUP BY GROUPING SETS (DenCl, DenPr, CAST ( DataFact AS CHAR( ) ), ( ) ) ORDER BY DenCl, DenPr, CAST (DataFact AS CHAR( ) ) CLIENT PRODUS ZIUA VINZARI  Clienţi SRL y-subtotal- y-subtotal-   Client SA y-subtotal- y-subtotal-   Client SRL y-subtotal- y-subtotal-   Client y-subtotal- y-subtotal-   Client SRL y-subtotal- y-subtotal-   Client SA y-subtotal- y-subtotal-   Client SRL y-subtotal- y-subtotal-   y-subtotal- Produs y-subtotal-   y-subtotal- Produs y-subtotal-   y-subtotal- Produs y-subtotal-   y-subtotal- Produs y-subtotal-   y-subtotal- Produs y-subtotal-   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal- y-subtotal-    Figura GROUPING SETS - exemplul Cele linii din figura sunt obţinute astfel: clienţi pentru care sunt vânzări, plus produse vândute, plus zile în care s-au întocmit facturi, plus linia totalului general Interesant este şi faptul că cei trei operatori pot fi combinaţi Spre exemplu, dacă GROUP BY are forma: GROUP BY GROUPING SETS ( ROLLUP (DenCl, DenPr), CAST( DataFact AS CHAR( )) ) prin execuţia consultării se obţin liniile din figura CLIENT PRODUS | ZIUA VINZARi  Iclient SRL Produs !y-subtotal-   Client SRL Produs ly-subtotal-   ICIient SRL Produs iy-subtotal-   I Client SRL y-subtotal- iy-subtotal-   ICIient SA Produs y-subtotal-   Client SĂ y-subtotal- y-subtotal-   Client SRL Produs y-subtotal-   (Client SRL Produs y-subtotal-   ICIient SRL Produs y-subtotal-   ICIient SRL Produs y-subtotal-   ICIient SRL y-subtotal- y-subtotal-   Client Produs y-subtotal-   Client Produs y-subtotal-   Client y-subtotal- y-subtotal-   Client SRL Produs y-subtotal-   Client SRL Produs y-subtotal-   Client SRL y-subtotal- y-subtotal-   Client SA Produs y-subtotal-   Client SA Produs y-subtotal-   Client SA Produs y-subtotal-   ICIient SA y-subtotal- y-subtotal-   Client SRL Produs y-subtotal-   Client SRL y-subtotal- y-subtotal-   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal-  - -   y-subtotal- y-subtotal-  - -   ly-subtotal- y-subtotal- ( - -  J  y-subtotal- y-subtotal-  - -   iy-subtotal- y-subtotal- y-subtotal-    CUBE-uri parţiale Discuţia se poartă în termeni similari ROLLUP-ului parţial Subtotalurile şi combinaţiile posibile sunt limitate la atributele-dimensiuni incluse între paranteze Spre exemplu, dacă GROUP BY are forma: GROUP BY atributl, CUBE (atribut , atribut ) vor fi calculate patru subtotaluri, pentru combinaţiile: (atributl, atribut , atribut ) - GROUP BY-ul obişnuit, (atributl, atribut ), (atributl, atribut ), (atributl) Versiune DB : IÎKSI SELECT CASE GROUPING (DenCl) WHEN THEN CONCAT (CHR( ), ' subtotal ') ELSE DenCl END AS Client, CASE GROUPING (DenPr) WHEN THEN CONCAT (CHR( ), 'subtotal ') ELSE DenPr END AS Produs, CASE GROUPING (CAST( DataFact AS CHAR( ) ) ) WHEN THEN CONCAT (CHR( ), ' subtotal ') ELSE CAST( DataFact AS CHAR( ) ) END AS Ziua, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCl GROUP BY DenCl, CUBE (DenPr, CAST( DataFact AS CHAR( ) ) ) ORDER BY DenCl, DenPr, CAST (DataFact AS CHAR( ) ) Tabelul CUBE parţial CLIENT PRODUS ZIUA VINZARI  Client SRL Produs  / /   Client SRL Produs  / /   Client SRL Produs  / /   Client SRL Produs y subtotal   Client SRL Produs  / /   Client SRL Produs  / /   Client SRL Produs  / /   Client SRL Produs  / /   Client SRL Produs  / /   Client SRL Produs y subtotal   Client SRL Produs  / /   Client SRL Produs y subtotal    Client SRL Produs  / /   Client SRL ysubtotai  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal Produs  / /   y subtotal ysubtotai  / /   y subtotal ysubtotai  / /   y subtotal ysubtotai  / /   y subtotal ysubtotai  / /   y subtotal ysubtotai  / /    Clasamente - soluţii clasice şi OLAP Prefaţăm discuţia despre funcţiile analitice din SQL- cu o problemă mai veche decât SQL-ul - clasamentele Să se afişeze clasamentul zilelor în ordinea descrescătoare a numărului de facturi emise Gradul de dificultate al interogărilor care să rezolve această problemă depinde de modul în care se doreşte a se obţine clasamentul Cine se mulţumeşte cu lista din figura poate folosi câteva interogări relativ simple DATAFACT NR FACTURILOR   - -    - -    - -    - -    - -    O variantă comună Oracle/DB , ba chiar şi VFP, este: SELECT DataFact, COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact ORDER BY Nr Facturilor DESC Ba chiar în Oracle se poate folosi şi o subconsultare în clauza FROM: SELECT DataFact, Nr Facturilor FROM (SELECT DataFact, COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact ) ORDER BY Nr Facturilor DESC iar în DB o expresie-tabelă: WITH ZILE FACT AS (SELECT DataFact, COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact) SELECT * FROM ZILE FACT ORDER BY Nr Facturilor DESC Ce ne facem însă atunci când rezultatul trebuie să îmbrace forma din figura ? Problema esenţială este nu ordonarea, cât indicarea poziţiei fiecărei zile DATAFACT NR FACTURILOR POZIŢIE   - -     - -     - -     - -     - -    Figura Un clasament veritabil în Oracle i este posibilă ordonarea liniilor unei subconsultări din clauza FROM, aşa că soluţia următoare, bazată pe pseudocoloana ROWNUM, funcţionează: SELECT DataFact, Nr Facturilor, ROWNUM AS Poziţie FROM (SELECT DataFact, COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact ORDER BY Nr Facturilor DESC) Chiar dacă ne putem declara satisfăcuţi de rezultat (figura ), se poate argumenta că august este pe nedrept „retrogradată” pe locul al clasamentului, atât timp cât are acelaşi număr de zile ca şi august şi nu există nici un criteriu suplimentar de departajare Interogarea de mai sus este corectă sută la sută atunci când fie toate valorile ordonate sunt diferite, fie când există un număr suficient de criterii de balotaj care să confere unicitate fiecărei poziţii a clasamentului DATAFACT NR FACTURILOR POZIŢIE   - -     - -     - -     - -     - -    Figura Pseudoclasamentul obţinut printr-o subconsultare Pentru astfel de situaţii, Amendamentul OLAP al SQL- prezintă două funcţii ideale, RANK şi DENSE RANK în prealabil însă, câteva chestiuni ce ţin de logica execuţiei unui asemenea gen de consultări Procesarea interogărilor ce utilizează funcţii analitice se derulează în trei etape Mai întâi, se operează toate joncţiunile, se constituie grupurile şi se efectuează selecţia asupra grupurilor, altfel spus, se execută clauzele JOIN (sau FROM/WHERE), WHERE, GROUP BY şi HAVING Apoi se aranjează rezultatul în vederea aplicării funcţiilor analitice şi se efectuează calculele (sunt create partiţiile), iar funcţiile analitice sunt aplicate linie cu linie în fiecare partiţie Pasul este operaţional numai dacă interogarea prezintă la sfârşit o clauză ORDER BY, ceea ce atrage ordonarea finală a rezultatului în conformitate cu criteriile specificate Partiţiile sunt seturi de linii create după delimitarea grupurilor prin GROUP BY, astfel încât pot constitui subiectul (sau obiectul) oricărei funcţii de agregare (SUM, AVG ) Constituirea unei partiţii se poate face în funcţie de valorile unuia sau mai multor atribute sau expresii de atribute Soluţia comună Oracle i /DB v pentru a obţine o situaţie identică celei din figura este: SELECT DataFact/ COUNT(*) AS Nr Facturilor, RANK() OVER (ORDER BY COUNT(*) DESC) AS Poziţie FROM FACTURI GROUP BY DataFact Funcţia RANK ierarhizează după valorile obţinute de COUNT (*) liniile rezultatului şi, ceea ce este cel mai important, la valori egale, atribuie fiecărei linii aceeaşi poziţie în clasament Luăm un alt exemplu care să pună în valoare şi partiţii Să se afişeze, pentru fiecare zi de vânzări, topul celor mai „ valoroase "facturi Să analizăm problema: partiţie are dimensiunea unei zile; numărul liniilor depinde de numărul facturilor întocmite în ziua respectivă; prin urmare, atributul de partiţionare este DataFact; în cadrul unei partiţii, clasamentul se face în funcţie de valorile calculate de funcţia SUM; în rezultatul final, pentru fiecare factură, liniile sunt dispuse în funcţie de valorile DataFact şi NrFact, deci la prezentare se păstrează ordinea cronologică Iată şi soluţia DB v şi Oracle i (rezultatul în figura ): SELECT DataFact, F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS ValFact, RANK() OVER (PARTITION BY DataFact ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Poziţie FROM PRODUSE P, LINIIFACT LF, FACTURI F WHERE P CodPr=LF CodPr AND LF NrFact=F NrFact GROUP BY DataFact, F NrFact ORDER BY DataFact, F NrFact ! DATAFACT | NRFACT VALFACT POZIŢIE   - - j     - -      - -      - -      - -      - -      - -      - -      - -      - -      - -     Figura Topurile zilnice ale facturilor Factura este a doua ca valoare pe august , cea mai mare valoare în această zi având factura Intr-o singură frază SELECT se pot întocmi, pentru aceleaşi date, clasamente diferite prin specificarea mai multor partiţii şi criterii Astfel, interogareâ (Oracle i /DB v ): SELECT DataFact, DenPr, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS ValFact, RANK() OVER (PARTITION BY DataFact ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Pozitie Zi, RANK() OVER (PARTITION BY DenPr ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Pozitie Prod FROM PRODUSE P, LINIIFACT LF, FACTURI F WHERE P CodPr=LF CodPr AND LF NrFact=F NrFact GROUP BY DataFact, DenPr ORDER BY DataFact, DenPr calculează valoarea vânzărilor pe zile (DataFact) pentru fiecare produs şi, în plus, determină poziţia produsului (DenPr) curent, atât pentru ziua respectivă, cât şi pe ansamblu, pentru toate combinaţiile zi-produs (Dat aFact-DenPr), după cum se observă în figura DATAFACT DENPR VALFACT :i|) POZIŢIE ZI POZITIE PROD   - - Produs  !    - - Produs  !    - - Produs      - - Produs      - - Produs      - - Produs      - - Produs L     - - Produs      - - Produs      - - Produs  ,     - - Produs      - - Produs      - - Produs      - - Produs      Pe prima linie a rezultatului apar ziua de august şi produsul , pentru care valoarea facturată în această zi este de este, ca mărime, a treia valoare pentru ziua respectivă şi a treia pentru produsul Altfel spus, pentru august , produsul este al treilea în topul pe produse al vânzărilor (cel mai bine vândut în această zi fiind produsul ), iar dintre toate zilele în care a fost vândut „Produs ”, august este a treia în topul vânzărilor pe zile (cel mai bine s-a vândut pe august) „Produs ” s-a vândut cel mai bine pe august şi cel mai puţin pe august; pe şi pe august a fost cel mai bine vândut produs al zilei Ziua de graţie a produsului a fost august, când a fost cel mai bine vândut produs al zilei şi data cu cele mai mari vânzări ale acestuia Se poate alcătui un clasament nu numai pe baza unei simple funcţii-agregat, dar şi prin combinarea funcţiei RANK cu funcţiile ROLLUP şi CUBE Rezultatele nu sunt însă întotdeauna concludente Spre exemplu, consultarea DB v următoare produce raportul din figura SELECT Judeţ, DenPr, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari, RANK() OVER (PARTITION BY Judeţ ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Poz Judet, RANK() OVER (PARTITION BY DenPr ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Poz Produs FROM PRODUSE P INNER JOIN LINIIFACT LF ON P CodPr=LF Codpr INNER JOIN FACTURI F ON LF NrFact=F NrFact INNER JOIN CLIENŢI C ON F CodCl=C CodCI INNER JOIN LOCALITATI L ON C CodPost=L CodPost INNER JOIN JUDEŢE J ON L Jud=J Jud GROUP BY ROLLUP (Judeţ, DenPr) ORDER BY Judeţ, DenPr JUDEŢ DENPR VINZARI POZ JUDET POZ PRODUS  lasi Produs     lasi Produs     lasi Produs     lasi      Neamţ Produs     Neamţ Produs     Neamţ Produs     Neamţ      Timiş Produs     Timiş Produs     Tirnis      Vaslui Produs     Vaslui Produs     Vaslui Produs     Vaslui Produs     Vaslui            Figura RANK şi ROLLUP Este limpede că Poz Judet va fi întotdeauna în liniile dedicate subtotalului pentru fiecare dintre judeţe „Produs ” nu este al patrulea ca vânzări în judeţul Iaşi, ci al treilea Valorile Poz Produs sunt însă coerente Judeţul în care „Produs '’ s-a vândut cel mai bine este Vaslui Cea mai importantă informaţie ţine de faptul că, dacă luăm în calcul liniile subtotalurilor şi totalului general, aflăm, spre exemplu, din penultima linie, că judeţul Vaslui este al treilea ca volum total al vânzărilor Poziţia exactă a Vasluiului în topul judeţelor este însă a doua, doarece prima îi revine automat totalului general (ultima linie) Lucrurile stau aidoma şi în cazul operatorului CUBE Deşi raportul (figura ) furnizat de următoarea frază SELECT, valabilă deopotrivă în Oracle i şi DB v , este bogat în informaţii, câteva dintre acestea trebuie nuanţate SELECT CASE WHEN GROUPING (DenCl) = THEN CONCAT (CHR( ), ' - SUBTOTAL - ') ELSE DenCl END AS Client, CASE WHEN GROUPING (DenPr) = THEN CONCAT (CHR( ), ' - SUBTOTAL - ') ELSE DenPr END AS Produs, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari, RANK() OVER (PARTITION BY DenCl ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Poz Client, RANK() OVER (PARTITION BY DenPr ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Poz Produs FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C, LOCALITATI L, JUDEŢE J WHERE P CodPr=LF Codpr AND LF NrFact=F NrFact AND F CodCl=C CodCI AND C CodPost=L CodPost AND L Jud=J Jud GROUP BY CUBE (DenCl, DenPr ) ORDER BY DenCl, DenPr CLIENT PRODUS VINZARI POZ CLIENT POZ PRODUS  Clienţi SRL Produs     Clienţi SRL Produs     Clienţi SRL Produs     Clienţi SRL y-SUBTOTAL-     Client SA Produs     Client SA y-SUBTOTAL-     Client SRL Produs     Client SRL Produs     Client SRL Produs     Client SRL Produs     Client SRL y- SUBTOTAL-     Client Produs  C    Client Produs     Client V- SUBTOTAL-     Client SRL Produs     Client SRL Produs     Client SRL y-SUBTOTAL-     Client SA Produs     Client SA Produs     Client SA Produs     Client SA y- S UBTOTAL -     Client SRL Produs     Client SRL y-SUBTOTAL-     y-SUBTOTAL- Produs     y- SUBTOTAL• Produs     y-SUBTOTAL- Produs     y-SUBTOTAL- Produs     y-SUBTOTAL- Produs     V- SUBTOTAL - V-SUBTOTAL-      Astfel, ca vânzări, pentru Client SRL, Produs este pe locul , şi nu pe locul , cum indică a doua linie din figură La modul general, Poz Client este tot timpul „umflat” cu o poziţie datorită subtotalurilor de la nivel de client şi, pentru ultimele linii, a totalului general Analog, capul listei pentru Poz Produs este cel al subtotalului pe produs, iar, spre exemplu, cel mai bun cumpărător al Produs este Client SRL Faptul că, la Produs , în dreptul Clientului SRL este indicată poziţia corectă, acest lucru se datorează vânzării produsului unui singur client Ţinând seama de interferenţa subtotalurilor, am fi tentaţi să decrementăm rezultatele funcţiilor RANK cu o unitate: SELECT CASE WHEN GROUPING (DenCl) = THEN CONCAT (CHR( ), ' - SUBTOTAL - ') ELSE DenCl END AS Client, CASE WHEN GROUPING (DenPr) = THEN CONCAT (CHR( ), ' - SUBTOTAL - ') ELSE DenPr • END AS Produs, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari, RANK() OVER (PARTITION BY DenCl ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) - AS Poz Client, RANK() OVER (PARTITION BY DenPrORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) - AS Poz Produs FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C, LOCALITATI L, JUDEŢE J WHERE P CodPr=LF Codpr AND LF NrFact=F NrFact AND F CodCl=C CodCl AND C CodPost=L CodPost AND L Jud=J Jud GROUP BY CUBE (DenCl, DenPr ) ORDER BY DenCl, DenPr Rezultatele ar fi perfecte dacă n-ar exista produse vândute unui singur client (Produs ) şi clienţi care au cumpărat un singur produs (Client şi Client ) Pentru aceste două speţe, Poz Client, respectiv Poz Produs sunt , chiar dacă respectivul produs/client ar fi singur şi poziţia ar trebui să fie, inevitabil, Am modificat, astfel, gluma aceea răsuflată: să alergi de unul singur şi ajungi pe locul zero! O soluţie mult mai elegantă se bazează pe modificarea modului de declarare a partiţiilor Pentru a pune în evidenţă cele două modalităţi, se afişează câte două poziţii pentru clienţi/produse, folosindu-se câte două funcţii RANK; una identică cu exemplul anterior şi o alta care beneficiază de serviciile GROUPING, după cum urmează: SELECT CASE WHEN GROUPING (DenCl) = THEN CONCAT (CHR( ), ' - SUBTOTAL - ') ELSE DenCl END AS Client, CASE WHEN GROUPING (DenPr) = THEN CONCAT (CHR( ), ' - SUBTOTAL - ') ELSE DenPr END AS Produs, SUM(Cantitate * PretUnit * ( +ProcTVA)) AS Vinzari, RANK() OVER (PARTITION BY DenCl ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Poz Client l, RANK() OVER (PARTITION BY DenCl, GROUPING(DenPr) ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Poz Client , RANK() OVER (PARTITION BY DenPr ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Poz Produs l, RANK() OVER (PARTITION BY DenPr, GROUPING (DenCl) ORDER BY SUM(Cantitate * PretUnit * ( +ProcTVA)) DESC) AS Poz Produs FROM PRODUSE P, LINIIFACT LF, FACTURI F, CLIENŢI C, LOCALITATI L, JUDEŢE J WHERE P CodPr=LF Codpr AND LF NrFact=F NrFact AND F CodCl=C CodCl AND C CodPost=L CodPost AND L Jud=J Jud GROUP BY CUBE (DenCl, DenPr ) ORDER BY GROUPING(DenCl), DenCl, GROUPING(DenPr), DenPr Coloanele Poz Client şi Poz Produs conţin, graţie includerii clauzelor GROUPING în funcţiile RANK, valorile care ne interesează - vezi figura CLIENT PRODUS VINZARI POZ CLIENTJ POZ CLIENT POZ PRODUS POZ PRODUS  Clienţi SRL Produs       Clienţi SRL Produs   ,     Clienţi SRL Produs       Clienţi SRL y- SUBTOTAL-    ,    Client SA Produs       Client SA y-SUBTOTAL-       Client SRL Produs       Client SRL Produs       Client SRL Produs       Client SRL Produs       Client SRL y-SUBTOTAL-       Client Produs       Client Produs       Client y-SUBTOTAL-       Client SRL Produs       Client SRL Produs       Client SRL y- SUBTOTAL-       Client SA Produs       Client SA Produs       Client SA Produs       Client SA y-SUBTOTAL-       Client SRL Produs       Client SRL y- SUBTOTAL-       y-SUBTOTAL- Produs       y-SUBTOTAL- Produs       y-SUBTOTAL- Produs       y-SUBTOTAL- Produs       y-SUBTOTAL- Produs       y-SUBTOTAL- ' y-SUBTOTAL -        Care sunt cele mai mari cinci preţuri unitare din LINIIFACT? In paragraful am prezentat o soluţie ingenioasă bazată pe subconsultări în cascadă O dată cu versiunea i, Oracle suportă ordonări în subconsultări, astfel încât următoarea frază este operaţională: SELECT PretUnit FROM (SELECT PretUnit FROM LINIIFACT ORDER BY PretUnit DESC) PI WHERE ROWNUM = PMAX PretUnit ORDER BY LF PretUnit DESC şi o alta comună Oracle i /DB v : SELECT DISTINCT NrFact, DenPr, LF PretUnit FROM LINIIFACT LF, PRODUSE P, (SELECT Poz, PretUnit FROM (SELECT PretUnit, ROW NUMBER () OVER (ORDER BY PretUnit DESC) AS Poz FROM LINIIFACT ) PI WHERE Poz = PMAX PretUnit ORDER BY LF PretUnit DESC Interogarea Oracle i : SELECT DataFact, Nr Facturilor, ROWNUM AS Poziţie FROM (SELECT DataFact, COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact ORDER BY Nr Facturilor DESC) WHERE ROWNUM = este incorectă, deoarece extrage numai una dintre cele două zile ( şi august) în care s-au emis câte patru facturi Cu toate acestea, rezultatul corect poate fi obţinut şi fară a apela la funcţia RANK, ci prin folosirea abuzivă a subconsultărilor şi a posibilităţii versiunii i de a ordona liniile oricărei subconsultări: SELECT ROWNUM AS Poziţie, TO CHAR(DataFact,'DD-MM-YYYY') AS Zi, Nr Facturilor FROM (SELECT DataFact, COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact HAVING COUNT(*) >= ANY (SELECT Nr Facturilor FROM (SELECT DISTINCT COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact ORDER BY Nr Facturilor DESC) WHERE ROWNUM = ANY ( SELECT Nr Facturilor FROM ( SELECT Nr Facturilor, ROW NUMBER() OVER (ORDER BY Nr Facturilor DESC) AS Poz FROM ( - SELECT DISTINCT COUNT(*) AS Nr Facturilor FROM FACTURI “ GROUP BY DataFact ) XI ) X WHERE X Poz = ANY (SELECT Nr Facturilor FROM (SELECT DISTINCT COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact ■ ORDER BY Nr Facturilor DESC) WHERE ROWNUM = ANY ( ' SELECT Nr Facturilor FROM (SELECT RANK() OVER (ORDER BY Nr Facturilor DESC) AS Poz, Nr Facturilor FROM (SELECT DISTINCT COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact) XI ) X WHERE Poz = ANY ( SELECT Nr Facturilor FROM (SELECT DENSE RANK() OVER (ORDER BY COUNT(*) DESC) AS Poz, COUNT(*) AS Nr Facturilor FROM FACTURI GROUP BY DataFact ) X WHERE Poz [ ] [ ] unde: : : = = I AUTHORIZATION I AUTHORIZATION identificator de autorizare > specificarea setului de caractere > : : = = DEFAULT CHARACTER SET element > : : = = definiţie domeniu > I I Atât obiectele, cât mai ales dicţionarul bazei, prezintă diferenţe semnificative de la SGBD la SGBD Dacă e să începem cu una dintre cele mai simple forme de dicţionar de date, putem face referire la containerul (database container) Visual FoxPro Acesta este o tabelă specială cu structura prezentată în figura ' Table Designer - vinzari dbc [Read Only] objectid Integer  ' JL   parentid Integer     obiecttype Character     obiectname Character     property Memo (binary)     code Memo (binary)     riinfo Character    t |user  Memo   El  ■*  Indexes Table Cancel Figura Structura containerului unei D în VFP Fiecare obiect din bază este identificat printr-un număr întreg unic - objectid Ierarhia obiectelor (de exemplu, atributele unei tabele) este reflectată prin câmpul parentid Tipologia obiectelor din container (atributul obj ecttype) este mai săracă în VFP: Database, Table, View, Field, Index şi Relation Dacă primele nu necesită comentarii, despre Relation trebuie spus că reflectă o legătură permanentă între două tabele, legătură ce nu asigură automat şi restricţiile referenţiale Procedurile stocate nu sunt un tip special, ci au trei obiecte corespondente, StoredProceduresSource, StoredProceduresObject şi StoredProceduresDependencies, toate de tipul Database în Oracle, lucrurile sunt cu mult mai analitice Dicţionarul este un set de tabele şi tabele derivate accesibile diferenţiat, în funcţie de rolul utilizatorului Dacă numele acestora este prefixat de USER, atunci este vorba despre obiecte ce aparţin utilizatorului curent; ALL desemnează, în plus, şi obiectele la care utilizatorul curent are acces, dar proprietarul este un alt utilizator, iar prefixul DBA (Data Base Administrator) se referă la toate obiectele bazei, indiferent de „proprietar” Tabela principală a catalogului este numită DICTIONARY şi are doar două coloane, TABLE NAME şi COMMENTS Aflarea tuturor tabelelor virtuale ce oferă informaţii despre obiectele din schemă este posibilă prin interogarea: SELECT * FROM DICTIONARY Pentru non administratori, inventarierea obiectelor din schema proprie (tabele, tabele virtuale, sinonime, proceduri, funcţii, pachete, secvenţe etc ) este posibilă folosind o altă tabelă din dicţionarul datelor - USER OBJECTS: SELECT * FROM USER OBJECTS DB (versiunea ) administrează două seturi de tabele derivate în cadrul dicţionarului de date, în schemele SYSCAT şi SYSSTAT Ambele seturi sunt accesibile utilizatorilor Tabelele virtuale din SYSSTAT reprezintă un subset al celor din SYSCAT, singurul avantaj fiind că o parte din atribute sunt actualizabile Despre crearea tabelelor am discutat pe îndelete în capitolul Am trecut în revistă principalele clauze pentru declararea restricţiilor: NOT NULL, PRIMARY KEY, UNIQUE, CHECK, FOREIGN KEY Ceea nu am prezentat în capitolul respectiv ţine de crearea unei tabele pe baza unei alte tabele, prin preluarea unuia sau mai multor atribute, eventual chiar definind noi atribute Spre exemplu, dacă în DB se doreşte ca din tabela FACTURI să se arhiveze toate facturile emise în într-o altă tabelă, denumită FACTURI , se poate folosi următoarea secvenţă de comenzi SQL: CREATE TABLE FACTURI AS (SELECT * FROM FACTURI) DEFINITION ONLY ; INSERT INTO FACTURI (SELECT * FROM FACTURI WHERE DataFact BETWEEN ' - - ' AND ' - - ' ) ; COMMIT ; Lucrurile nu diferă prea mult în Oracle, dar crearea tabelei FACTURI şi popularea sa pot fi realizate dintr-o singură mişcare: CREATE TABLE FACTURI AS (SELECT * FROM FACTURI WHERE DataFact BETWEEN TO DATE(' - - ','YYYY-MM-DD') AND TO DATE(' - - ','YYYY-MM-DD')) în Visual FoxPro, crearea unei tabele printr-o combinaţie CREATE TABLE / SELECT nu este posibilă Prin clauza FROM ARRAY, o tabelă poate prelua structura şi conţinutul unui masiv (ARRAY) Revenind la problema noastră, rezolvarea este la fel de simplă, dar folosind clauza INTO: SELECT * ; FROM FACTURI ; INTO TABLE FACTURI ; WHERE DataFact BETWEEN {'' - - } AND {^ - - } Tot în capitolul prezentam clauza CHECK pentru declararea unor restricţii la nivel de atribut Din păcate, nici unul dintre dialectele SQL ale celor trei produse - DB , Oracle şi VFP - nu suportă clauza SQL- legată de folosirea subconsultărilor Spre exemplu, dacă dorim ca în tabela LINIIFACT să instituim restricţia ca, în urma oricărei modificări a acestei tabele, să nu existe nici o factură fără măcar o linie, în SQL- se poate specifica: ALTER TABLE liniifact ADD CONSTRAINT macar o linie CHECK (EXISTS (SELECT FROM facturi WHERE facturi NrFact=liniifact NrFact)) Nici în privinţa domeniilor şi aserţiunilor implementările SQL ale produselor comerciale nu stau grozav, aşa că în continuare ne ocupăm de tabele virtuale, de proceduri stocate şi declanşatoare în VFP, dacă se doreşte extragerea tuturor tabelelor din bază, se foloseşte o consultare relativ simplă: SELECT * FROM vinzari dbc WHERE OBJECTTYPE= Table' Răspunsul este cel din figura Atributul Property furnizează, prin altele (numele fişerului DBF de pe disc, indexul primar al tabelei), şi numele eventualelor declanşatoare ale tabelei       rJ Qi   Objectid | Parenlid Obiecttype Objectname Property I Code I Riinfo | Useil *   ei  ! Table I judeţe Memo memo; j memo!     • T âble j localitati Memo memo ; imemo!    !  ! Table I clienţi Memo memo i imemo!     Table ! persoane Memo memo i imemo!    i  ! Table ! persclienti Memo memo ; memo!    !  ! Table i produse Memo memo ; memo!    !  Table j facturi Memo memo j i memo!    i  ! Table i liniifact Memo memo memo!    !  ! Table ! incasari Memo memo! memoi    !  Table I incasfact Memo memo; : memoi ,   ? ! In  Figura Extragerea din containerul BD în VFP a informaţiilor despre tabele Informaţii despre atributele tabelelor pot fi obţinute în mod asemănător: SELECT v objectname, vl objectid, vl objectname, ; left(vl property, ) ; FROM vinzari dbc vi INNER JOIN vinzari dbc v ; ON vl parentid=v objectid ; WHERE v OBJECTTYPE='Table' AND vl OBJECTTYPE='Field' ; ORDER BY VI objectid Din păcate, modul de prezentare a valorilor implicite, regulilor de validare şi mesajelor de eroare afişate la încălcarea regulilor de validare la nivel de câmp este destul de criptic şi dificil de folosit în aplicaţii Dată fiind structura mult mai analitică a dicţionarului bazei (catalogul-sistem), în Oracle sunt necesare mai multe interogări: pentru aflarea tabelelor din schema curentă: SELECT TABLE NAME FROM USER TABLES pentru aflarea tuturor tabelelor, tabelelor virtuale, sinonimelor şi secvenţelor din schema utilizatorului curent: SELECT TABLE NAME, TABLE TYPE FROM USER CATALOG pentru afişarea informaţiilor despre atributele unei tabele: SELECT * FROM USER TAB COLUMNS WHERE TABLE NAME='FACTURI pentru listarea informaţiilor despre tabelele derivate: SELECT * FROM USER VIEWS afişarea restricţiilor din schema curentă: SELECT * FROM USER CONSTRAINTS Lucrurile stau oarecum asemănător şi în DB : tabelele din schema FOTACHEM: SELECT * FROM SYSCAT TABLES WHERE TABSCHEMA='FOTACHEM' tabelele virtuale: SELECT * 'FROM SYSCAT VIEWS WHERE VIEWSCHEMA='FOTACHEM' informaţii despre atributele unei tabele: SELECT * FROM SYSCAT COLUMNS WHERE TABNAME='FACTURI'  restricţiile de tip CHECK din tabela FACTURI: SELECT * FROM SYSCAT COLUMNS WHERE TABNAME='FACTURI' coloanele tabelei FACTURI pentru care au fost declarate restricţii de tip CHECK: SELECT * FROM SYSCAT COLCHECKS WHERE TABNAME='FACTURI' Tabele virtuale în Oracle şi VFP în mod obişnuit, tabelele derivate sunt percepute ca tabele noi, construite prin subconsultări aplicate asupra tabelelor de bază sau altor view-uri Standardul SQL- defineşte view-urile ca tabele virtuale ce sunt materializate atunci când este invocat numele lor Materializarea înseamnă, de fapt, execuţia frazei SELECT ce constituie definiţia tabelei virtuale şi popularea cu înregistrări care sunt, de fapt, rezultatul interogării Formatul general al comenzii de creare a unei asemenea tabele virtuale este: CREATE VIEW [ ] AS [WITH [ ] CHECK OPTION] unde ::= CASCADED | LOCAL O dată creată tabela virtuală, definiţia sa este salvată în schema bazei Ulterior, ori de câte ori este necesar, la deschiderea/reîmprospătarea tabelei derivate, aceasta este (re)populată cu înregistrări extrase din cele ale tabelelor propriu-zise ce apar în clauza FROM a interogării O tabelă virtuală poate fi deci privită şi ca o expresie de subconsultare a unei tabele persistente, stocată în bază şi invocată prin numele său Potrivit SQL- , unei tabele virtuale nu i se pot asocia indecşi şi nici defini restricţii, deşi unele SGBD-uri optimizează lucrul cu view-urile folosind indecşii tabelelor persistente Numele său este unic şi nu se poate autoreferi, deşi un view poate fi creat pe baza unei combinaţii de tabele persistente şi/sau alte view-uri SQL- introduce şi noţiunea de tabelă derivată, definită asemănător celei virtuale, dar pentru care se pot defini restricţii şi asocia indecşi, fiind, spre deosebire de tabela virtuală, persistentă AS [ ] în ceea ce ne priveşte, acest paragraf este dedicat tabelelor virtuale, problematica expusă fiind o continuare a ceea ce a fost deja prezentat în paragraful După cum am văzut atunci, cele mai dificile probleme ale view-urilor ţin de actualizarea lor, de fapt, de propagarea actualizărilor tabelelor virtuale în tabelele de bază din care sunt construite La creare, o tabelă virtuală poate fi declarată actualizabilă sau non-actualizabilă (Read-Only) Pentru a fi actualizabilă, o tabelă virtuală trebuie să aibă fiecare linie a sa asociată unei singure linii din tabelele bazei La modificarea unei linii din view, propagarea poate fi făcută, în aceste condiţii, fără probleme de ambiguitate Fireşte, o tabelă derivată de genul: CREATE VIEW vJudetel AS SELECT * FROM Judeţe WHERE regiune = 'Moldova' OR regiune = 'Dobrogea' nu va crea probleme insolubile la actualizare în schimb, deşi cu un conţinut identic vJudetel, tabela virtuală vJudete , creată prin comanda care urmează, nu este actualizabilă nici în SQL- , nici în majoritatea SGBD-urilor importante CREATE VIEW vJudete AS SELECT * FROM Judeţe WHERE regiune = 'Moldova' UNION SELECT * FROM Judeţe WHERE regiune = 'Dobrogea' Regulile actualizării tabelelor în SQL- sunt foarte stricte : Tabela virtuală trebuie derivată dintr-un SELECT cu o singură tabelă de bază; mai multe tabele de bază înseamnă mai multe niveluri ale tabelelor virtuale Spre exemplu, pentru a construi o tabelă virtuală vCLIENTI în care pot fi modificate: denumirea clientului, adresa sa, denumirea localităţii în care îşi are sediul şi numele judeţului, sunt necesare următoarele view-uri: CREATE VIEW vJudete AS SELECT * FROM Judeţe CREATE VIEW vLocalitati AS SELECT CodPost, Loc, vJudete Jud, Judeţ, Regiune FROM LOCALITATI INNER JOIN vJUDETE ON LOCALITATI Jud = vJUDETE Jud CREATE VIEW vClienti AS SELECT CodCI, DenCl, Adresa, vLocalitati CodPost, Loc, Jud, Judeţ, Regiune FROM CLIENŢI INNER JOIN VLOCALITATI ON CLIENŢI CodPost = VLOCALITATI CodPost  Tabelele virtuale trebuie să includă toate coloanele cheilor primare/alternative ale tabelelor de bază O linie dintr-o tabelă virtuală trebuie să corespundă unei singure linii din tabela de bază Toate coloanele neincluse în view trebuie să permită valori NULL sau să prezinte valori implicite Altminteri, inserarea unei linii într-o tabelă derivată ar fi imposibilă Nu poate fi actualizată o tabelă virtuală creată prin fraze SELECT în care apar: clauze GROUP BY / HAVING, funcţii-agregat, coloane calculate, UNION, » INTESECT, EXCEPT (MINUS), SELECT DISTINCT Din punctul de vedere al actualizării tabelelor virtuale, SQL- este mult mai limitat decât o cer regulile lui Codd, preferându-se siguranţa Multe SGBD-uri sunt însă mai îngăduitoare în această privinţă Mai mult, în SQL- şi o serie de SGBD-uri, prin mecanisme de genul declanşatoarelor INSTEAD OF, multe probleme ale tabelelor virtuale, insolubile în SQL- , îşi găsesc rezolvarea Atunci când tabela virtuală este actualizabilă, se poate folosi clauza WITH CHECK OPTION pentru un mai bun control al modificărilor vJudeteMoldova conţine înregistrările tabelei JUDEŢE pentru care valoarea atributului Regiune este Moldova-, ' CREATE VIEW vJudeteMoldova AS SELECT * FROM judeţe WHERE Regiune='Moldova' WITH CHECK OPTION Comanda INSERT în formatul: INSERT INTO vJudeteMoldova VALUES ('BC', ’Bacau', 'Moldova') se execută, fără probleme, ceea ce nu este valabil şi pentru: INSERT INTO vJudeteMoldova VALUES ('AR', 'Arad', 'Banat') care va genera un mesaj de eroare din cauza regiunii ce nu este acceptată în tabela virtuală, graţie clauzei CHECK OPTION în SQL- , clauza de verificare este, implicit, declanşată în cascadă (CASCADED), adică atât pentru tabela virtuală curentă, cât şi pentru cele pe baza cărora a fost construită, nivel cu nivel Cu toate acestea, CASCADED se poate înlocui cu LOCAL, caz în care se verifică numai WHERE-ul prezentei tabele virtuale, fară a se testa modul în care modificările afectează tabelele derivate de pe nivelurile inferioare Ştergerea unei tabele virtuale din schema bazei de date se realizează prin comanda DROP VIEW - DROP VIEW cnume-tabelă-virtuală> unde ::= CASCADE | RESTRICT Prin clauza CASCADE se şterg atât tabela virtuală curentă, cât şi toate cele create pe baza acesteia, în timp ce RESTRICT interzice operaţiunea atâta timp cât există măcar un view construit pe baza tabelei virtuale curente Tabele virtuale în Oracle în Oracle, aflarea atât a frazei SELECT de creare, cât şi a modului în care o tabelă derivată poate fi actualizată presupune consultarea dicţionarului de date Spre exemplu, interogarea prin care a fost creată vJudeteMoldova se vizualizează prin: SELECT TEXT FROM USER VIEWS WHERE VIEW NAME = 'VJUDETEMOLDOVA' iar interogarea: SELECT column name, updatable, insertable, deletable FROM user updatable columns WHERE table name = 'VJUDETEMOLDOVA' va determina afişarea rezultatului din figura COLUMN NAME | UPDATABLE INSERTABLE DELETABLE  JUD YES YES YES  JUDEŢ YES YES YES  REGIUNE YES YES YES   Figura Posibilităţi de actualizare în tabela derivată vJudeteMoldova Rezultă că asupra acestei tabele derivate poate fi operată toată gama de operaţiuni pentru toate atributele în schimb, dacă pe baza acesteia creăm o alta pentru vizualizarea şi actualizarea localităţilor din judeţul Iaşi: CREATE VIEW vLocJudlasi AS SELECT localitati codpost, localitati loc, localitati jud, judeţ, regiune FROM localitati, vJudeteMoldova WHERE localitati jud = vJudeteMoldova jud AND localitati jud='IS' WITH CHECK OPTION situaţia se prezintă diferit - vezi figura COLUMN NAME UPDATABLE INSERTABLE DELETABLE  CODPOST YES YES YES  LOC YES YES YES  JUD NO NO NO  JUDEŢ NO NO NO  REGIUNE NO NO NO   Prin urmare, orice tentativă de a modifica ultimele trei atribute va eşua Ba mai mult, nici inserarea nu funcţionează Comanda: INSERT INTO vLocJudlasi VALUES (' ', 'Tg Frumos', 'IS', 'Iasi', 'Moldova') va genera mesajul de eroare: ORA- : virtual column not allowed here Chiar dacă schimbăm definiţia în: CREATE OR REPLACE VIEW vLocJudlasi AS SELECT localitati codpost, localitati loc, localitati jud, judeţ, regiune FROM localitati, judeţe WHERE localitati jud = judeţe jud AND localitati jud='IS' WITH CHECK OPTION rezultatul va fi identic Prin urmare, în vLodasi este posibilă numai modificarea atributelor CodPost şi Loc Aceste probleme majore de actualizare în Oracle i pot fi rezolvate cu ajutorul declanşatoarelor, după cum vom vedea peste câteva pagini Tabele virtuale în Visual FoxPro Visual FoxPro este un produs generos în ceea ce priveşte tabelele derivate Acestea pot fi create atât grafic, cât şi prin program Important este că pot fi definite explicit atributele care pot fi actualizate sau nu, modul de actualizare a tabelelor, ba chiar, mai mult, se pot defini indecşi şi reguli de validare chiar la nivel de view Programul prezentat în listingul este grăitor în acest sens Listing Program Visual FoxPro de creare a unei tabele derivate *** CREAREA TABELEI DERIVATE vFacturi IINCLUDE foxpro h IF IDBUSED('vinzari') OPEN DATABASE vinzari ENDIF SET DATABASE TO vinzari IF USED('vFacturi') SELECT vFacturi USE ENDIF Fraza SQL de creare a tabelei virtuale CREATE SQL VIEW vFacturi AS ; SELECT LF NrFact, F DataFact, Linie, LF CodPr, DenPr, ; UM, Cantitate, PretUnit, Cantitate * PretUnit AS ; ValFaraTVA, Cantitate * PretUnit * ProcTVA AS TVA, ; Cantitate * PretUnit * ( + ProcTVA) AS ValTotala ; FROM LINIIFACT LF INNER JOIN FACTURI F ON LF NrFact=F NrFact ; INNER JOIN PRODUSE P ON LF CodPr=P CodPr ; ORDER BY LF NrFact, Linie Pe baza tabelei derivate, se va actualiza numai LINIIFACT DBSETPROP('vFacturi', 'View', 'Tables', 'LINIIFACT') Se declara atributele cheie (primara) DBSETPROP('vFacturi NrFact', 'Field', 'KeyField', t ) DBSETPROP('vFacturi Linie', 'Field', 'KeyField', t ) Se declara ca actualizabile atributele cheie primara DBSETPROP('vFacturi NrFact', 'Field', 'Updatable', t ) DBSETPROP('vFacturi Linie', 'Field', 'Updatable', t ) Tipul modificărilor (UPDATE, nu INSERT-DELETE) DBSETPROP('vFacturi', 'View', 'UpdateType', DB UPDATE) La propagarea actualizarii in tabelele de baza, se verifica daca au intervenit modificări in continutul atributelor cheie si a celor actualizabile DBSETPROP('vFacturi', 'View', ’WhereType', DB KEYANDUPDATABLE) Semnalul final pentru propagarea modificărilor din tabela derivata in cea de baza DBSETPROP('vFacturi', 'View', 'SendUpdates', t ) RETURN O dată creată, tabela derivată trebuie deschisă explicit prin comanda USE, operaţiune în urma căreia are loc execuţia frazei SELECT şi popularea cu înregistrări De remarcat că împrospătarea tabelei derivate cu cele mai noi înregistrări ale tabelelor de bază nu necesită închiderea şi deschiderea sa, funcţia REQUERY () asigurând acest lucru Afişarea tabelelor derivate din baza de date se obţine asemănător tabelelor „normale”: SELECT * FROM vinzari dbc WHERE OBJECTTYPE='View' Atributul Property conţine fraza SELECT pe baza căreia a fost construită tabela virtuală Cât despre obţinerea datelor despre atributele tabelelor derivate, iată interogarea: SELECT v objectname, vl objectid, vl objectname, ; left(vl property, ) ; FROM vinzari dbc vl INNER JOIN vinzari dbc v ; ON vl parentid=v objectid ; WHERE v OBJECTTYPE='View' AND vl OBJECTTYPE='Field' ; ORDER BY vl objectid Proceduri şi funcţii stocate în VFP şi Oracle Dacă procedura sau funcţia reprezintă noţiuni vânturate de multe decenii de informaticienii cu sau fară acte în regulă, asocierea acestora cu persistenţa a fost consacrată de SGBD-urile deceniului al tocmai încheiatului secol Stocarea se referă la „înăuntrul” bazei, în dicţionarul de date sau catalogul sistemului, cum i se spune la case (de soft) mai mari Deşi puternic impregnate cu SQL, funcţiile şi procedurile stocate sunt, după cum bine le zice numele, cam procedurale, depinzând într-o măsură decisivă de extensiile proprietare ale fiecărui SGBD Dintre procedurile stocate, în acest paragraf ne ocupăm de funcţiile ce întorc valori implicite pentru atribute, proceduri/funcţii de validare, iar în paragraful următor, de un tip special de proceduri stocate, şi anume declanşatoarele (trigger-ele) Valori implicite O problemă importantă a bazelor de date o reprezintă cheile-surogat, valori ale unor atribute care nu au legătură directă cu realitatea, dar ajută la identificarea de o manieră unică a liniilor unei tabele Spre exemplu, în tabela CLIENŢI, atributul CodCl este o cheie- -surogat, fiind un număr unic atribuit fiecărui client, fără o logică anume La fel putem spune despre CodPr din tabela PRODUSE şi Codlnc din ÎNCASĂRI Din contra, CodPost din LOCALITĂŢI, Jud din JUDEŢE, CNP din PERSOANE, NrFact sunt informaţii cu alt grad de relevanţă şi standardizare Modul în care se pot genera valori implicite pentru atribute de tip chei-surogat diferă de la caz la caz în Oracle, valorile secvenţiale unice pot fi generate printr-un tip special de obiecte ale bazei denumite „secvenţe”, dar care nu pot fi referite în clauza DEFAULT, ci numai în declanşatoare DB -ul permite, la crearea unei tabele, declararea de câmpuri autoincrementate, astfel: CREATE TABLE clienţi ( codci DECIMAL( ) NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH , INCREMENT BY ), dencl VARCHAR( ) ) ; , Orice linie inserată ulterior în tabela CLIENŢI va primi, pentru atributul CodCl, valoarea următoare, obţinută prin secvenţa declarată prin clauzele START WITH - INCREMENT BY Poate paradoxal, Visual FoxPro este mult mai generos în materie de funcţii stocate pentru calculul valorilor implicite ale unor atribute Pentru atributul CodCl din tabela CLIENŢI se doreşte ca valorile implicite să fie „returnate” de funcţia def codcl clienti () Comanda declarativă este: ALTER TABLE CLIENŢI ALTER COLUMN CodCl ; SET DEFAULT def codcl clienti() Procedurilor stocate ale bazei de date VÂNZĂRI (al cărei program de creare a fost discutat în capitolul ) li se adaugă şi liniile din listingul Listing Procedura stocată VFP DEF C DCL CL ENTI ************************************** PROCEDURE def codcl clienti 'k'k-k-k'k-k'k'k'k-k'k-k-k-k-k'k-k-kic'k'k'k'k'fc-k'k-k'k-k'k-k'k-k-k'k'k'k'k LOCAL vCodCl DIME vCodCl( , ) vCodCl( , ) = SE LECT MAX (CodCl) FROM clienţi INTO ARRAY vCodCl IF vCodCl( , ) = RETURN ELSE RETURN vCodCl( , ) + ENDIF ENDPROC Spre deosebire de alte SGBD-uri, în VFP funcţiile ce întorc valori implicite pot fi oricât de sofisticate Lucrul acesta nu trebuie exagerat, deoarece poate afecta viteza de lucru a aplicaţiei Ne fixăm ca obiectiv crearea unei funcţii stocate care să determine Cel mai frecvent client, adică acel client care apare pe cele mai multe facturi, iar codul acestuia să constituie valoarea implicită pentru atributul CodCI din tabela FACTURI: ALTER TABLE FACTURI ; ALTER COLUMN CodCI SET DEFAULT def codcl facturi() In listingul se află corpul funcţiei (în procedurile stocate ale bazei de date): Listing Corpul procedurii stocate VFP ************************************* PROCEDURE def codcl facturi ************************************* LOCAL vCodCl DIME vCodCl( , ) vCodCl = SELECT TOP CodCI, COUNT(*) AS nr ; FROM FACTURI ; INTO ARRAY vCodCl ; GROUP BY CodCI ; ORDER BY nr DESC IF vCodCl( , ) = MESSAGEBOX('Nu se pot introduce facturi, '+CHR( )+; 'cita vreme nu exista nici un client !') RETURN F ELSE RETURN vCodCl( , ) ENDIF ENDPROC Intrând şi mai mult în detalii, luăm în discuţie tabela LINIIFACT Cheia primară a acesteia este combinaţia (NrFact, Linie) Trei atribute sunt susceptibile de a se procopsi cu valori implicite calculate prin funcţii stocate, NrFact, Linie şi CodPr Logica acestora este diferită Spre exemplu, este de presupus că factura curentă, pentru care se introduc linii, este cea mai recentă (are cel mai mare număr) Numărul liniei trebuie incrementat, iar produsul propus de funcţia stocată trebuie să fie cel mai frecvent facturat, însă nu trebuie să violeze unicitatea combinaţiei (NrFact, CodPr)! ALTER TABLE LINIIFACT ALTER COLUMN NrFact ; SET DEFAULT def nrfact liniifact() ALTER TABLE LINIIFACT ALTER COLUMN Linie ; SET DEFAULT def linie liniif act () ALTER TABLE LINIIFACT ALTER COLUMN CodPr ; SET DEFAULT def codpr liniifact() Listingul prezintă codul acestor trei funcţii stocate: Listing Alte trei proceduri stocate VFP ************************************** PROCEDURE def nrfact liniifact ************************************** LOCAL vNrFact DIME vNrFar" ( ) vNrFact = se selecte: cea mai recenta factura SELECT MAX(Nruact) ; FROM FACTURI ; INTO ARRAY vNrFact IF vNrFact (l, ) = MESSAGEBOX('Nu se pot introduce linii daca nu exista nici o; factura !') RETURN F ELSE RETURN vNrFact ENDIF ENDPROC ************************************** PROCEDURE def linie liniifact ************************************** LOCAL vLinie , NrFact DIME vLinie (l, ) vLinie = NrFact = LINIIFACT NrFact se extrage ultima linie introdusa in factura curenta SELECT MAX(Linie) ; FROM LINIIFACT ; INTO ARRAY vLinie ; WHERE NrFact = NrFact IF vLinie (l,l) = && e prima linie din factura RETURN ELSE && se incrementează RETURN vLinie ( , ) + ENDIF ENDPROC ************************************** PROCEDURE def codpr liniifact ************************************** LOCAL vCodPr , NrFact DIME vCodPr ( , ) vCodPr = NrFact = LINIIFACT NrFact ** se selecteaza cel mai frecvent produs, exceptindu-le pe cele care c‘ ** ar viola unicitatea combinaţiei (NrFact, CodPr) SELECT TOP CodPr, COUNT(*) AS nr ; FROM LINIIFACT ; INTO ARRAY vCodPr ; WHERE CodPr NOT IN ; (SELECT CodPr ; FROM LINIIFACT ; WHERE NrFact = NrFact ) ; GROUP BY CodPr ; ORDER BY nr DESC IF vCodPr ( , ) = MESSAGEBOX('Nu se mai pot introduce produse pe aceasta ; factura !') RETURN F ELSE RETURN vCodPr ( , ) ENDIF ENDPROC Cât priveşte regulile de validare complexe, intenţiile generoase din SQL- , de folosire a subconsultărilor în clauze CHECK, nu prea au fost preluate în SGBD-urile comerciale, însă logica acestora poate fi inclusă în totalitate în declanşatoare (triggere), pe care le vom discuta în următorul paragraf Poate că ar mai merita amintit că în VFP pot avea asociate reguli de validare nu numai atribute ale unor tabele, ci şi ale unor tabele derivate Astfel, dacă dorim ca în tabela derivată vFacturi atributele NrFact, Linie şi CodPr să primească aceleaşi valori implicite ca şi în tabela LINIIFACT, comenzile sunt: =DBSETPROP('vFacturi NrFact' , 'FIELD', 'DefaultValue', ; 'def nrfact liniifact() ' ) =DBSETPROP('VFACTURI Linie' , 'FIELD', 'DefaultValue', ; 'def linie liniifact() ' ) =DBSETPROP('VFACTURI CodPr', 'FIELD', 'DefaultValue', ; 'def codpr liniifact()') Funcţii stocate şi fraze SELECT în Visual FoxPro în afara funcţiilor şi procedurilor stocate de tipul regulilor de validare, valorilor implicite sau declanşatoarelor, o facilitate importantă a VFP o constituie posibilitatea folosirii funcţiilor stocate în fraze SQL Să se afişeze, pentru fiecare client, valoarea vânzărilor, încasărilor şi restul de plată La soluţiile pur neprocedurale SQL adăugăm una care presupune crearea în baza de date a două funcţii, după cum urmează (listingul ): Listing Două funcţii VFP stocate, utilizate în interogări ************ + *****-*****•*************** PROCEDURE f vinzari cl PARAMETER codcl LOCAL suma ' DIME suma ( , ) suma = SELECT SUM(cantitate * pretunit * ( + proctva)) ; INTO ARRAY suma ; FROM facturi f INNER JOIN liniifact lf ON f nrfact=lf nrfact ; INNER JOIN produse p ON lf codpr=p codpr ; WHERE codcl = codcl RETURN suma ENDPROC ************************************** ************************************** PROCEDURE f incasari cl PARAMETER codcl LOCAL suma DIME suma ( , ) suma = SELECT SUM(transa) ; INTO ARRAY suma ; FROM facturi f INNER JOIN incasfact i ON f nrfact=i nrfact ; WHERE codcl = codcl RETURN suma ENDPROC ************************************** Cele două funcţii pot fi folosite în orice frază SELECT după cum urmează: SELECT dencl, ; f vinzari cl (codcl) AS vinzari, ; f incasari cl (codcl) AS incasari, ; f vinzari cl (codcl) - f incasari cl (codcl) ; AS rest de plata ; FROM CLIENŢI Care este cel mai mare datornic dintre clienţi? Este una dintre problemele cele mai dificile formulate în capitolul , la care în VFP, singurele soluţii se bazau pe salvarea rezultatelor intermediare în cursoare Iată o altă interogare, mult mai simplă, care se foloseşte de aceleaşi două proceduri stocate: SELECT dencl, ; f vinzari cl (codcl) AS vinzari, ; f incasari cl (codcl) AS incasari, ; f vinzari cl (codcl) - f incasari cl (codcl) ; AS rest de plata ; FROM CLIENŢI ; WHERE f vinzari cl (codcl) - f incasari cl (codcl) = ; (SELECT MAX(f vinzari cl (codcl) - ; f incasari cl (codcl)) ; FROM CLIENŢI) Nu este neapărat ca funcţiile de tipul f vinzari cl şi f incasari cl să fie stocate Frazele SELECT pot fi incluse în programe ce includ şi descrierea funcţiilor-argument în acest mod se evită aglomerarea containerului (dicţionarului) bazei Care este contribuţia procentuală a fiecărui produs la totalul vânzărilor? După cura observaţi, am trecut deja la OLAP Răspunsul la această întrebare presupune folosirea interogărilor scalare în DB şi a funcţiilor OLAP în Oracle i Varianta VFP pe care v-o propunem se bazează pe două funcţii stocate, prezentate în listingul Listing Funcţii stocate pentru calculul vânzărilor pe produse şi vânzărilor totale ■k’k-k-k'k-kic-k-k-kic-k-k'k-k-k-k-k-k-k'k'k-k'k-k-k-k-k-k-k-k-k'k'k-k-k-k-k PROCEDURE vinz prod PARAMETER codpr LOCAL suma DXME suma (l,l) suma = SELECT SUM(cantitate * pretunit * ( + proctva)) ; INTO ARRAY suma ; FROM liniifact lf INNER JOIN produse p ON lf codpr=p codpr ; WHERE lf codpr = codpr RETURN suma ENDPROC ************************************** PROCEDURE total vinzari LOCAL suma DIME suma ( , ) suma = SELECT SUM(cantitate * pretunit * ( + proctva)) ; INTO ARRAY suma ; FROM liniifact lf INNER JOIN produse p ON lf codpr=p codpr RETURN suma ENDPROC ************************************** Iată şi interogarea care le foloseşte şi furnizează răspunsul la problema formulată: SELECT denpr AS Produs, vinz prod (codpr) AS Vinzari, ; total vinzari() AS total, ; ROUND(vinz prod (codpr) / total vinzari() * , ) ; AS Procent ; FROM PRODUSE Care este evoluţia zilnică a vânzărilor, prin raportare la ziua calendaristică anterioară? Este nevoie de două funcţii, al căror corp este prezentat în listingul Listing Funcţii pentru calculul vânzărilor unei zile şi zilei precedente 'k'k'k'k'k’k-k'k-k-k'k'k'k-k'k'k'k'k'k'k’k'k'k'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k PROCEDURE f vinzari zi PARAMETER data LOCAL suma DIME suma (l, ) suma = SELECT SUM(cantitate * pretunit * ( + proctva)) ; INTO ARRAY suma ; FROM facturi f INNER JOIN liniifact lf ; ON f nrfact=lf nrfact ; INNER JOIN produse p ON lf codpr=p codpr ; WHERE datafact = data RETURN suma ENDPROC 'k-k'k'k-k-k'k-k-k'k'k-k'k-k-k-k'k'k'k-k'k-k'k'k-k-k-k'k-k-k-k'k-k + 'k'k'k'k •k'k-k-k'k-k-k-k'k'k'k'k'k'k-k-k'k-k-k'k-k'k-k'k'k'k'k-k-k-k-k-k'k'k'k'k'k'k PROCEDURE f vinzari zi prec PARAMETER data RETURN f vinzari zi (data - ) ENDPROC ■k-k'k-k'k-k'k'k'k-k'k'k'k'k-k-k'k-k-k-k'k'k'k'k'k'k'k-k'k'k'k'k-k-k-k'k'k-k în final, iată şi interogarea: SfiLECT DISTINCT datafact AS Zi, ; f vinzari zi (datafact) AS Vinzari Zi Curenta, ; f vinzari zi prec (datafact) AS Vinzari Zi Precedenta, ; f vinzari zi (datafact) - f vinzari zi prec (datafact) ; AS Diferenţa ; FROM FACTURI Sigur, acest stil de lucru poate oripila pe mulţi ideologi şi convertiţi la SQL, dar până la apariţia interogărilor scalare şi funcţiilor OLAP în Visual FoxPro nu prea avem de ales Funcţii stocate şi fraze SELECT în Oracle Modul de lucru prezentat mai sus funcţionează şi în Oracle Este adevărat, în Oracle se poate discuta despre nivelul de puritate al funcţiilor, obligatoriu pentru cele incluse în pachete Ca model, prezentăm în listingul scriptul de creare a celor două funcţii şi echivalentele funcţiilor VFP cu aceleaşi nume din listingul Listing Crearea în Oracle a funcţiilor stocate, utilizate în interogări CREATE OR REPLACE FUNCTION f vinzari cl ( codcl IN clienţi codcl%TYPE ) RETURN NUMERIC IS suma NUMERIC ( ) ; BEGIN ' SELECT SUM(cantitate * pretunit * ( + proctva)) INTO suma 'FROM FACTURI F, LINIIFACT LF, PRODUSE P WHERE F NrFact = LF NrFact AND LF CodPr = P CodPr AND codcl = codcl ; RETURN suma ; END ; CREATE OR REPLACE FUNCTION f incasari cl ( codcl IN clienţi codcl%TYPE ) RETURN NUMERIC IS suma NUMERIC ( ) := ; BEGIN ' SELECT SUM(transa) INTO suma ' FROM FACTURI F, INCASFACT I WHERE F NrFact = I NrFact AND CodCI = CodCl ; RETURN suma ; END ; / Cât priveşte interogarea care le foloseşte, nu sunt deosebiri faţă de VFP: SELECT dencl, f vinzari cl (codcl) AS vinzari, f incasari cl (codcl) AS incasari, f vinzari cl (codcl) - f incasari cl (codcl) AS rest de plata FROM CLIENŢI Ar mai fi de adăugat că pentru a afla numele şi alte informaţii despre funcţiile şi procedurile stocate din schema curentă, se poate interoga catalogul sistem: SELECT * FROM USERjDBJECTS WHERE OBJECT TYPE = 'FUNCTION' respectiv: SELECT * FROM USERJDBJECTS WHERE OBJECT TYPE = 'PROCEDURE' în schimb, corpul funcţiilor/procedurilor este conţinut în altă tabelă a dicţionarului - USER SOURCE Astfel, pentru a vizualiza conţinutul funcţiei AF DENCL, este necesara consultarea: SELECT line, text FROM USER SOURCE WHERE TYPE = 'FUNCTION' AND NAME='AF DENCL' în DB , informaţii despre funcţiile stocate într-o schemă (FOTACHEM) pot fi vizualizate prin interogarea: SELECT * FROM SYSCAT FUNCTIONS WHERE FUNCSCHEMA='FOTACHEM' ■ Analog stau lucrurile cu procedurile stocate: SELECT * FROM SYSCAT PROCEDURES WHERE PROCSCHEMA='FOTACHEM' Declanşatoare în VFP şi Oracle Declanşatoarele (triggere, în original) reprezintă un tip deosebit de proceduri stocate ale unei baze de date Particularitatea lor esenţială ţine de faptul că, o dată create şi stocate în schema bazei, acestea sunt executate automat ia operaţiuni de inserare, modificare sau ştergere a liniilor din tabela pentru care au fost definite La această familie a declanşatoarelor, unele SGBD-uri au mai adăugat şi alte tipuri, asociate, spre exemplu, actualizărilor tabelelor derivate, conectării unei aplicaţii/utilizator, deschiderii şi închiderii instanţei baze de date etc Pentru lucrarea de faţă, problema principală a declanşatoarelor ţine de faptul că acestea sunt scrise în extensiile procedurale ale SQL care prezintă diferenţe sensibile de la produs la produs: PL/SQL (Oracle), DB , Transact-SQL (SQL Server) etc Este drept că în SQL- există o parte special dedicată procedurilor stocate, dar preluarea pe scară largă a specificaţiilor standardului în produsele marilor actori ai pieţei SGBD-urilor va lua ceva timp Cele mai importante avantaje ale declanşatoarelor sunt: permit instituirea unor reguli de validare cu mult mai complexe decât ceea ce permite clauza CHECK; pot ameliora sensibil mecanismul de securitate al bazei; permit instituirea (acolo unde nu este posibil prin clauza FOREIGN KEY) restricţiilor referenţiale şi modului de tratare a modificărilor ce pot cauza probleme de integritate referenţială; constituie suportul calculării automate a valorilor unor atribute într-o abordare de la simplu la complex, vom urmări câteva aspecte ale declanşatoarelor în Visual FoxPro şi Oracle i Declanşatoare în VFP Problematica declanşatoarelor în VFP am prezentat-o in extenso într-un articol publicat în PC Report împreună cu Cătălin Strîmbei Fără a intra prea mult în detalii, în VFP există trei tipuri de declanşatoare: pentru inserare, modificare şi ştergerea de linii Momentul declanşării lor depinde esenţial de tipul de Buf fering ales, o chestiune specifică VFP în cele ce urmează, presupunem că opţiunea de huffering este dezactivată Declanşatoare pentru restricţii referenţiale Mecanismul de asigurare a restricţiilor referenţiale se poate implementa grafic cu ajutorai modulului Referenţial Integrity Builder Paradoxal, deşi există clauza FOREIGN KEY, aceasta instituie în VFP numai legături permanente între tabele De aceea, la crearea prin program a bazei de date sunt necesare declanşatoare „manuale”, care, totuşi, au avantajul că permit afişarea unor mesaje de eroare în clar sau afişarea unor restricţii şi explicaţii suplimentare Să începem cu tabela JUDEŢE Ştergerea unui judeţ poate aduce necazuri dacă există localităţi în acel judeţ (mă refer la baza de date ) Aşa încât este necesar un declanşator de ştergere care să verifice dacă eliminarea înregistrării poate avea loc sau nu Comanda de creare a declanşatorului este: CREATE TRIGGER ON judeţe FOR DELETE AS trg del judete() Iată, în listingul , corpul declanşatorului Listing Varianta a declanşatorului TRG DEL JUDETE ************************************** PROCEDURE trg del judete ************************************** LOCAL jud , v dime v( , ) v = ' • jud = judeţe jud SELECT MIN(loc) FROM localitati INTO ARRAY v WHERE jud = jud IF v(l,l) # ' ' MESSAGEBOX( Exista cel puţin o linie copil in ; tabela LOCALITATI '+; CHR( )+'Exemplu: loc '+ALLTRIM(v( , ))) RETURN F ENDIF ENDPROC ************************************** SQL beneficiază de câteva optimizări ale motorului bazei date Cu toate acestea, SELECT-ul din declanşator parcurge întreaga tabelă LOCALITĂŢI, aşa încât pare mai rapidă varianta următoare - ce-i drept, mai puţin SQL-istă Listing Varianta a declanşatorului TRG DEL JUDETE ************************************** PROCEDURE trg del judete ************************************** LOCAL jud jud = judeţe jud IF INDEXSEEK(jud , F , 'localitati', 'jud') MESSAGEBOX('Exista cel puţin o linie copil in ; tabela LOCALITATI !') RETURN F ENDIF ENDPROC ************************************** Funcţia INDEXSEEK caută în tabela LOCALITĂŢI, fară a deplasa pointerul pentru înregistrări, prima linie pentru care cheia indexului JUD (cheie care este atributul cu acelaşi nume) are aceeaşi valoare ca a variabilei j ud Când căutarea este încununată de succes, valoarea retumată este TRUE ( T în notaţia VFP), altminteri, FALSE Modificarea indicativului unui judeţ trebuie să se propage şi în tabela LOCALITĂŢI, ocazie bună pentru încă un declanşator: CREATE TRIGGER ON judeţe FOR UPDATE AS trg upd judete() Corpul declanşatorului este prezentat în listingul Valoarea dinaintea modificării se obţine în VFP prin funcţia OLDVAL () Listing Declanşator pentru modificarea unei linii din tabela JUDEŢE -k-k-k-k-k-k-k-k-k-k-k-k-k-k-kie-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k PROCEDURE trg upd judete ************************************** LOCAL jud OLD, jud NEW j ud NEW = judeţe jud jud OLD = OLDVAL('jud', 'judeţe') IF jud NEW # jud OLD UPDATE localitati SET jud = jud NEW WHERE jud = jud OLD ENDIF ENDPROC La inserarea unei noi linii într-o tabelă-copil sau la schimbarea valorii unei chei străine, trebuie verificat dacă noile valori se regăsesc în tabela-părinte Spre exemplu, dacă în tabela LOCALITĂŢI se modifică valoarea atributului Jud, această nouă valoare trebuie căutată în JUDEŢE Se poate crea, în acest scop, un declanşator: CREATE TRIGGER ON localitati FOR UPDATE ; AS trg upd localitati() Trebuie, însă, să avem în vedere că modificarea atributului Jud din LOCALITĂŢI poate fi şi consecinţa declanşatorului trg upd judete Aşa încât, pentru a evita circularitatea, se verifică dacă modificarea este una locală sau provine din declanşatorul cu pricina - vezi listingul Listing Declanşator TRG UPD LOCALITATI ************************************** PROCEDURE trg upd localitati ************************************** LOCAL jud OLD, jud NEW, codpost OLD, codpost NEW, v ; DIME v(l,l) ~ *** mai intii se verifica restrictia referentiala cu tabela părinte jud NEW = localitati jud jud OLD = OLDVAL('jud', 'localitati') IF jud NEW # jud OLD IF TRIGGERLEVEL MESSAGEBOX('Noul client e prea datornic si ; nu-i mai vindem nimic !!!') RETURN F ENDIF ENDIF *** se interzice modificarea interactiva a atributului ValTotala valtotala NEW = facturi valtotala valtotala OLD = OLDVAL('valtotala', 'facturi') IF valtotala NEW # valtotala OLD IF TRIGGERLEVEL Presupunând că de clienţi au codul mai mare decât , un trigger de modificare la nivel de linie se execută de de ori, în timp ce unul la nivel de comandă o singură dată Dacă nici un client nu are codul mai mare de , un trigger de modificare la nivel de linie nu s-ar putea executa deloc, în timp ce declanşatorul declarat a fi la nivel de comandă ar fi lansat (evident, o singură dată) Declanşatoare de tip înainte (BEFORE) şi după (AFTER) actualizare O altă diferenţiere (în bine) faţă de declanşatoarele VFP este posibilitatea de a defini momentul acţiunii trigger-ului Un trigger de tip BEFORE intră în acţiune înainte de modificarea propriu-zisă şi este ideal pentru verificarea unui set de condiţii care ar putea bloca de la bun început tranzacţia respectivă (autentificări, soldul pentru un cont sau pentru un material într-o magazie etc ) Declanşatorul de tip AFTER se execută după momentul producerii actualizării, servind la verificarea corectitudinii operaţiunii (nu a fost scoasă din magazie o cantitate de material mai mare decât stocul dinaintea operaţiunii), inserarea unei linii într-o tabelă de tip jurnal (ce ţine evidenţa strictă a modificărilor operate în tabele cu informaţii sensibile - spre exemplu, calculul automat al costului mediu ponderat al unui material după fiecare intrare în magazie sau calculul soldului curent al unui cont bancar după fiecare depunere sau retragere etc ) Spre deosebire de cele de tip BEFORE, trigger-ele de tip AFTER blochează liniile procesate Declanşatoarele la nivel de linie/comadă pot fi combinate cu cele de tip BEFORE/ AFTER Astfel, pentru orice tabelă şi operaţie de inserare/modificare/ştergere pot fi definite patru tipuri de triggere care se execută în ordinea: înainte - la nivel de comandă (BEFORE - statement) înainte - la nivel de linie (BEFORE - row) după-la nivel de linie (AFTER-row) după - la nivel de comandă (AFTER - statement) Triggere de tip în-loc-de (INSTEAD OF) Acest gen de declanşator constituie un excelent mijloc de propagare a modificărilor dintr-o tabelă derivată în tabelele de bază din care provine Amânăm această discuţie pentru finalul capitolului Un alt element foarte important este că şi în trigger-e le la nivel de linie de tip BEFORE, şi în cele de tip AFTER pot fi invocate şi prelucrate atât valorile atributelor dinaintea operaţiei, cât şi cele de după operaţie Prefixul este, după caz, : OLD sau : NEW (vă amintiţi că în VFP aveam nevoie de funcţia OLDVAL ()) Declanşatoare pentru generarea cheilor-surogat După cum am mai discutat, în Oracle nu pot fi definite, nici pentru valorile implicite, nici pentru regulile de validare, funcţii-utilizator Lucrurile pot fi însă aranjate utilizând declanşatoare Spre exemplu, pentru ca un client nou să primească codul următor, se poate declara un declanşator la nivel de linie prin care, înaintea inserării noii linii, valoarea CodCI să fie obţinută de o manieră similară VFP - vezi listingul Listing Declanşatorul pentru inserarea unei înregistrări în tabela CLIENŢI - varianta CREATE OR REPLACE TRIGGER trg clienti ins befo row BEFORE INSERT ON clienţi FOR EACH ROW DECLARE cc clienţi codclITYPE ; BEGIN SELECT MAX(codcl) INTO cc FROM clienţi ; :NEW codcl := NVL(cc , ) + ; END ; Chiar dacă comanda de inserare are forma: INSERT INTO clienţi VALUES ( , 'Client ', NULL, NULL, ' ', NULL) ; valoarea atributului CodCl în noua linie nu va fi , ci calculată prin declanşator O altă variantă a acestui declanşator utilizează secvenţele Secvenţa permite unei aplicaţii să preia numere consecutive unice pe un anumit interval Gestiunea secvenţei se face la nivelul central; fiecare apel care „cere” o valoare din secvenţă poate fi absolut sigur că nici un alt apel nu va primi o valoare identică, deci nu vor apărea conflicte O secvenţă se creează prin comanda CREATE SEQUENCE Pentru ca noii clienţi să primească coduri unice, în ordinea preluării în tabelă, se poate folosi secvenţa seq clienti codcl creată după cum urmează: CREATE SEQUENCE seq clienti codcl INCREMENT BY MINVALUE MAXVALUE NOCYCLE ORDER O dată creată, referinţa la o secvenţă se face prin NextVal, caz în care se obţine valoarea următoare a secvenţei (incrementarea se face automat), în timp ce valoarea curentă a secvenţei se obţine prin CurrVal Astfel încât, pentru ca un client nou să aibă codul imediat superior ultimului client introdus în tabelă, se foloseşte declanşatorul trg clienti ins befo row, care se execută automat înaintea adăugării unei noi înregistrări în tabela CLIENŢI Listing Declanşator pentru inserarea unei linii în tabela CLIENŢI - varianta CREATE OR REPLACE TRIGGER trg clienti ins befo row BEFORE INSERT ON clienţi FOR EACH ROW DECLARE cc clienţi codcl%TYPE ; BEGIN y \°c INTO cc FROM DUAL ; :NEW codcl := cc ; END ; Declanşatoare pentru restricţii referenţiale în Oracle, cea mai mare parte a restricţiilor referenţiale sunt rezolvate prin opţiunile comenzii CREATE TABLE Astfel, ştergerea unei înregistrări-părinte, valoarea eronată a unei chei străine sunt sancţionate prompt de SGBD Principala problemă referenţială rămasă nerezolvată în Oracle este actualizarea în cascadă a unui atribut-părinte în toate înregistrările-copil Această opţiune (UPDATE CASCADE) poate fi implementată, cel puţin deocamdată, numai cu ajutorul declanşatoarelor Spre exemplu, creăm un declanşator pentru propagarea modificărilor atributului Jud din JUDEŢE în tabela LOCALITĂŢI - listingul Listing Declanşator pentru modificarea atributului jud in tabela JUDEŢE CREATE OR REPLACE TRIGGER trg judete upd jud after row AFTER UPDATE OF jud ON judeţe REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW BEGIN UPDATE localitati SET jud = :NEW jud WHERE jud = :OLD jud ; END ; Atribute actualizate prin declanşatoare Pentru comparaţie cu VFP, în listingul este prezentat declanşatorul pentru modificarea unei linii a tabelei LINIIFACT, declanşator ce recalculează valoarea totală a facturii Listing Crearea declanşatorului TRG LINIIFACT UPD AFTER ROW CREATE OR REPLACE TRIGGER trg liniifact upd after row AFTER UPDATE OF NrFact, CodPr, Cantitate, PretUnit ON liniifact FOR EACH ROW DECLARE ■ v proctva OLD produse proctva%TYPE ; v proctva NEW produse proctva%TYPE ; BEGIN variabile globale v trg liniifact upd after row := TRUE ; SELECT ProcTVA INTO v proctva OLD FROM produse WHERE codpr = :OLD codpr ; IF :NEW codpr O :OLD codpr THEN daca s-a schimbat codpr e posibil si procentul TVA sa fie altul SELECT ProcTVA INTO v proctva NEW FROM produse WHERE codpr = :NEW codpr ; ELSE procent TVA neschimbat v proctva NEW := v proctva OLD ; END IF ; IF :NEW nrfact <> :OLD nrfact THEN s-a modificat nrfact, deci trebuie decrementată Valtotala pt factura veche si incrementată pentru factura noua UPDATE facturi SET valtotala = valtotala - :OLD cantitate * :OLD PretUnit * ( + v proctva OLD) WHERE nrfact = :OLD nrfact ; UPDATE facturi SET valtotala = valtotala + :NEW cantitate * :NEW pretunit * ( + v proctva NEW) WHERE nrfact — :NEW nrfact ; ELSE UPDATE facturi SET valtotala = valtotala - :OLD cantitate * :OLD PretUnit *( + v proctva OLD) + :NEW cantitate * :NEW PretUnit * ( + v proctva NEW) WHERE nrfact = :NEW nrfact ; END IF ; variabile globale v trg liniifact upd after row := FALSE ; END ; Ca o noutate apare şi variabila publică v trg liniifact upd after row, care este TRUE numai pe parcursul declanşatorului O variabilă are un regim public în PL/SQL prin intermediul unui pachet (dacă apare în specificaţiile pachetului) Listingul de creare a pachetului variabile globale este prezentat peste câteva pagini Declanşatoare pentru controlul actualizărilor Păstrând similitudinea cu declanşatoarele VFP, îl construim pe cel de modificare a tabelei FACTURI, în care trebuie să se interzică actualizarea atributului ValTotala altfel decât prin declanşatorul trg liniif act upd after row Listing Prima variantă a declanşatorului TRG FACTURI UPD AFTER ROW CREATE OR REPLACE TRIGGER trg facturi upd after row AFTER UPDATE ON facturi FOR EACH ROW DECLARE v vinzari facturi valtotala%TYPE ; v incasari facturi valtotala%TYPE ; BEGIN variabile globale v trg facturi upd after row := TRUE ; IF :NEW vaitotala o :OLD valtotala AND NOT variabile globale v trg liniifact upd after row THEN variabile globale v trg facturi upd after row := FALSE ; RAISE AP PLICATION ERROR(- , 'Este interzisa modificarea directa a ValTotala !'); END IF ; IF :NEW codcl O :OLD codcl THEN SELECT SUM (cantitate * pretunit * ( + proctva)) INTO v vinzari FROM facturi f, liniifact lf, produse p WHERE f nrfact=lf nrfact AND lf codpr=p codpr AND codcl=:NEW codcl ; SELECT SUM(transa) INTO v incasari FROM facturi f, incasfact i WHERE f nrfact=i nrfact AND codcl = :NEW codcl ; IF v vinzari - v incasari > THEN variabile globale v trg facturi upd after row := FALSE ; RAISE APPLICATION ERROR(- , 'Clientul e prea mare datornic !'); END IF ; END IF ; IF :NEW nrfact o : LD nrfact THEN UPDATE liniifact SET nrfact = :NEW nrfact WHERE nrfact = :OLD nrfact ; UPDATE incasfact SET nrfact = :NEW nrfact WHERE nrfact = :OLD nrfact ; END IF ; variabile globale v trg facturi upd after row := FALSE ; END ; Dacă la comanda UPDATE facturi SET valtotala = WHERE nrfact=llll ; declanşatorul se comportă onorabil, afişând mesajul de eroare: ERROR at line : ORA- : Este interzisa modificarea directa a ValTotala ! ORA- : at "FOTACHEM TRG FACTURI UPD AFTER ROW", line ORA- : error during execution of trigger FOTACHEM TRG FACTURI UPD AFTER ROW' în schimb, la modificarea lui CodCI pentru o factură: UPDATE facturi SET codcl - WHERE nrfact = ; facem cunoştinţă cu o problemă „clasică” din Oracle: UPDATE facturi SET codcl = WHERE nrfact = * ERROR at line : ORA- : table FOTACHEM FACTURI is mutating, trigger/function may not see it ORA-O : at "FOTACHEM TRG FACTURI UPD AFTER ROW", line ORA- : error during execution of trigger 'FOTACHEM TRG FACTURI UPD AFTER ROW' Tabela FACTURI nu poate fi modificată deoarece, în termeni oraclişti, este mutantă O tabelă este mutantă (mutating) dacă se află în curs de modificare printr-o comandă INSERT, UPDATE sau DELETE sau trebuie modificată ca efect al unei restricţii referenţiale de tip DELETE CASCADE O tabelă este restricţionată (constraining) dacă declanşatorul o accesează direct, printr-o comandă SQL, sau indirect, în virtutea unei restricţii referenţiale Pentru toate declanşatoarele de la nivel de linie şi cel de la nivel de comandă (statement) lansat ca urmare a unei ştergeri în cascadă (prin opţiunea DELETE CASCADE de la CREATE/ALTER TABLE) există câteva restricţii menite să prevină situaţiile de inconsistenţă a datelor: într-un declanşator nu poate fi citită sau modificată o tabelă mutantă (în curs de modificare) datorită trigger-ului Este ceea ce ni s-a întâmplat în FACTURI, când declanşatorul citeşte tabela pentru calculul valorilor facturate şi încasate ale noului client ' într-un trigger nu pot fi modificate atributele ce alcătuiesc cheile primară şi străine, precum şi cele pentru care a fost declarată restricţia de unicitate, atribute ale unei tabele restricţionate (pentru trigger-ul respectiv) Excepţie fac trigger-ele de inserare la nivel de linie prin care se adaugă o singură înregistrare Pentru a rezolva problema apărută, modificăm corpul declanşatorului de mai sus şi creăm un declanşator la nivel de comandă Mai înainte, în listingul este prezentat pachetul variabilelor publice Listing Crearea pachetului cu variabile publice CREATE OR REPLACE PACKAGE variabile globale IS ~ v trg facturi upd befo sta BOOLEAN := FALSE ; v trg facturi upd befo row BOOLEAN := FALSE ; v trg facturi upd after row BOOLEAN := FALSE ; v trg facturi upd after sta BOOLEAN := FALSE ; v trg liniifact upd befo sta BOOLEAN := FALSE ; v trg liniifact upd befo row BOOLEAN : = FALSE ; v trg liniifact upd after row BOOLEAN := FALSE ; v trg liniifact upd after sta BOOLEAN := FALSE ; v codcl NEW clienţi codcl%TYPE ; v codcl OLD clienţi codcl%TYPE ; END ; în noua versiune a declanşatorului TRG FACTURI UPD AFTER ROW se memorează, în variabilele publice v codcl NEW şi v codcl OLD, vechea şi noua valoarea a atributului CodCI Aceste două valori sunt folosite în noul declanşator, cel de la nivel de comandă, în care scăpăm de problema „mutanţei”: Listing Varianta a declanşatorului TRG FACTURI UPD AFTER ROW CREATE OR REPLACE TRIGGER trg facturi upd after row AFTER UPDATE ON facturi FOR EACH ROW DECLARE v vinzari facturi valtotala%TYPE ; v incasari facturi valtotala%TYPE ; BEGIN variabile globale v trg facturi upd after row := TRUE ; variabile globale v codcl OLD := :OLD codcl ; variabile globale v codcl NEW := :NEW codcl ; IF :NEW valtotala O :OLD valtotala AND NOT variabile globale v trg liniifact upd after row THEN variabile globale v trg facturi upd after row := FALSE ; RAISE APPLICATION ERROR(- , 'Este interzisa modificarea directa a ValTotala !'); END IF ; IF :NEW nrfact <> :OLD nrfact THEN UPDATE liniifact SET nrfact = :NEW nrfact WHERE nrfact = :OLD nrfact ; UPDATE incasfact SET nrfact = :NEW nrfact WHERE nrfact = :OLD nrfact ; END IF ; variabile globale v trg facturi upd after row := FALSE ; END ; în final, listingul conţine scriptul pentru crearea declanşatorului la nivel de comandă: Listing Crearea declanşatorului TRG FACTURI UPD AFTER STA CREATE OR REPLACE TRIGGER trg facturi upd after sta AFTER UPDATE ON facturi DECLARE v vinzari facturi valtotala%TYPE ; v incasari facturi valtotala%TYPE ; BEGIN variabile globale v trg facturi upd after sta := TRUE ; IF variabile globale v codcl OLD o variabile globale v codcl NEW THEN SELECT SUM (cantitate * pretunit * ( + proctva)) INTO v vinzari FROM facturi f, liniifact lf, produse p WHERE f nrfact=lf nrfact AND lf codpr=p codpr AND codcl = variabile globale v codcl NEW ; SELECT SUM(transa) INTO v incasari FROM facturi f, incasfact i WHERE f nrfact=i nrfact AND codcl = variabile globaie v codcl NEW ; IF v vinzari - v incasari > THEN văriabile globale v trg facturi upd after sta :=FALSE; RAISE APPLICATION ERROR(- , 'Clientul e prea mare datornic !'); END IF ; END IF ; variabile globale v trg facturi upd after sta := FALSE ; END ; Declanşatoare de tip INSTEAD OF în Oracle i După cum promiteam în paragraful dedicat tabelelor derivate, în Oracle i problemele legate de actualizarea acestora şi, implicit, propagarea modificărilor în tabelele persistente, se pot rezolva mai mult decât onorabil utilizând declanşatoare INSTEAD OF Revenim la tabela virtuală vLocJudlasi creată prin joncţiunea tabelelor JUDEŢE şi LOCALITĂŢI Inserarea unei linii în view înseamnă, în primul rând, adăugarea unei noi localităţi în plus, trebuie verificat dacă valoarea atributului Jud există în JUDEŢE Dacă nu, atunci este vorba despre un judeţ nou-nouţ şi se inserează o nouă linie în JUDEŢE Iată, în listingul , blocul PL/SQL de creare a declanşatorului ce realizează aceste operaţiuni Listing Bloc PL/SQL de creare a declanşatorului TRG VLOCJUDIASI INS INSTEAD CREATE OR REPLACE TRIGGER trg vlocjudiasi ins instead INSTEAD OF INSERT ON vlocjudiasi DECLARE jud JUDEŢE Jud%TYPE ; ' BEGIN BEGIN SELECT Jud INTO jud FROM judeţe WHERE jud = :NEW Jud ; EXCEPTION WHEN NO DATA FOUND THEN INSERT INTO judeţe VALUES (:NEW Jud, :NEW Judeţ, :NEW Regiune) ; END ; INSERT INTO localitati VALUES (:NEW CodPost, :NEW Loc, :NEW Jud) ; Analog pot fi create declanşatoare pentru modificări şi ştergeri ale liniilor din tabela virtuală Toate informaţiile despre declanşatoarele tabelelor sau tabelelor virtuale din schema curentă, inclusiv corpul lor (blocul PL/SQL), pot fi obţinute din tabela USER TRIGGERS a catalogului-sistem Spre exemplu, situaţia trigger-elor tabelei LINIIFACT este vizualizată astfel: SELECT * FROM USER TRIGGERS WHERE TABLE NAME = 'LINIIFACT' CUPRINS Cuvânt, oarecum, înainte , * * Conţin uitul lucrării Capitolul NOŢIUNI ALE MODELULUI RELAŢIONAL Baze de date şi sisteme de gestiune a bazelor de date Niveluri de abstractizare a datelor s , Sisteme de gestiune a bazelor de date , ^ Limbaje de definire a datelor Limbaje de manipulare a datelor , - Gestionarul bazei "" Administratorul bazei de date ^ Utilizatorii bazelor de date -,g Un pic de istorie recentă şi relaţională j Relaţii/tabele, domenii şi atribute Restricţii ale bazei de date „c Z© Restricţia de domeniu «o Atonicitate „„ Restricţia de unicitate Restricţia referenţială ' Restricţii-utilizator " j j Schema şi conţinutul unei baze de date Exemplu Conentarii suplimentare privind restricţiile referenţiale Alte noţiuni ale SGBD-urilor relaţionale Tatele virtuale (View-uri) , Proceduri stocate * Regulile modelului relaţional [Korth&Silberschatz ], pp - ; [Everest ], pp - [Everest ], p Preluare din [Korth&Silberschatz ], p [Adiba&Delobel ], citaţi în [Saleh ], p Pentru detalii legate de obiectivele vizate de Codd atunci când a formulat modelul relaţional, vezi şi [Date - ] Pentru amănunte privind odiseea System R, vezi şi http://www mcjones org/System R/SQL Reunion Preluare din PC World România, iunie , p , Pentru o discuţie in extenso a atomicităţii şi a primei forme normalizate, vezi [Fotache - ], Beech, D - „New Life for SQL”, Datamation, februarie Vezi [Celko ], p [Celko ], p [Date ], pp - [Boyce ş a ], Preluare din [Hemandez&ViescaOO], pp - • O variantă SQL- /DB este: SELECT F NrFact, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I CodInc,l)) AS Facturat, SUM(VALUE(Transa, ))/ MAX(LF Linie) AS încasat, SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I,Codlnc, )) - SUM (VALUE (Transa, Cţ) ) / MAX (LF Linie) AS Diferenţa, CASE WHEN SUM(VALUE(Transa, ))/ MAX(LF Linie) = THEN 'Fara nici o incasare WHEN SUM(Cantitate * PretUnit * ( +ProcTVA)) / COUNT(DISTINCT VALUE( I Codlnc, )) > SUM(VALUE(Transa, ))/ MAX(LF Linie) THEN 'încasata parţial' ELSE 'ÎNCASATA TOTAL' END AS Situatiune [Date ], p 